RedHat has issued an advisory on June 3: https://rhn.redhat.com/errata/RHSA-2013-0896.html According to the CVE, this is fixed upstream after 1.4.1, and we have 1.5.0 in Cauldron, so I'll assume it isn't affected. Mageia 2 and Mageia 3 are affected. Patched packages uploaded for Mageia 2 and Mageia 3. For the Mageia 3 update I had to put my programmer hat on for a second to get one of the patch rediffs to build, so hopefully I didn't break anything. Also, please check that the advisory information is appropriate, as it was copied from RedHat and indicates a need for some manual intervention with this update. Advisory: ======================== Updated qemu packages fix security vulnerability: It was found that QEMU Guest Agent (the "qemu-ga" service) created certain files with world-writable permissions when run in daemon mode (the default mode). An unprivileged guest user could use this flaw to consume all free space on the partition containing the qemu-ga log file, or modify the contents of the log. When a UNIX domain socket transport was explicitly configured to be used (not the default), an unprivileged guest user could potentially use this flaw to escalate their privileges in the guest (CVE-2013-2007). Note: This update requires manual action. Refer below for details. This update does not change the permissions of the existing log file or the UNIX domain socket. For these to be changed, stop the qemu-ga service, and then manually remove all "group" and "other" permissions on the affected files, or remove the files. Also note that after installing this update, files created by the guest-file-open QEMU Monitor Protocol (QMP) command will still continue to be created with world-writable permissions for backwards compatibility. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2007 https://rhn.redhat.com/errata/RHSA-2013-0896.html ======================== Updated packages in core/updates_testing: ======================== qemu-1.0-6.5.mga2 qemu-img-1.0-6.5.mga2 qemu-1.2.0-8.1.mga3 qemu-img-1.2.0-8.1.mga3 from SRPMS: qemu-1.0-6.5.mga2.src.rpm qemu-1.2.0-8.1.mga3.src.rpm Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA2TOO
Testing complete mga3 64 Before ------ Found basic help with qemu-ga --help Confirmed with.. $ qemu-ga -d -v -l ~/test/qemu-ga.log -f ~/test/qemu-ga.pid $ ll test total 8 -rw-rw-rw- 1 claire claire 78 Jun 5 15:58 qemu-ga.log -rw------- 1 claire claire 4 Jun 5 15:58 qemu-ga.pid After ----- $ rm -f test/* $ qemu-ga -d -v -l ~/test/qemu-ga.log -f ~/test/qemu-ga.pid $ ll test total 8 -rw------- 1 claire claire 78 Jun 5 16:09 qemu-ga.log -rw------- 1 claire claire 5 Jun 5 16:09 qemu-ga.pid Also installed the dualcd in virt-manager
Whiteboard: MGA2TOO => MGA2TOO has_procedure mga3-64-ok
Testing mga2 32 It doesn't appear to be affected to the same degree. Before ------ $ qemu-ga -d -v -l ~/test/qemu-ga.log -f ~/test/qemu-ga.pid $ ll test total 8 -rw-r--r-- 1 claire claire 78 Jun 5 16:18 qemu-ga.log -rw------- 1 claire claire 4 Jun 5 16:18 qemu-ga.pid After ----- $ rm -f test/* $ qemu-ga -d -v -l ~/test/qemu-ga.log -f ~/test/qemu-ga.pid $ ll test total 8 -rw-r--r-- 1 claire claire 78 Jun 5 16:20 qemu-ga.log -rw------- 1 claire claire 4 Jun 5 16:20 qemu-ga.pid The update doesn't appear to make any difference, could you check David please.
Whiteboard: MGA2TOO has_procedure mga3-64-ok => MGA2TOO has_procedure feedback mga3-64-ok
Mga3 32 testing complete So the problem is mga2 rather than 32bit
Whiteboard: MGA2TOO has_procedure feedback mga3-64-ok => MGA2TOO has_procedure feedback mga3-64-ok mga3-32-ok
Well that's ironic. mga3 is where I had to put my programmer hat on for a bit. The RedHat patches I used were for an even older qemu (actually about the same qemu-kvm version we had in mga1) and were just a simple rediff on mga2. The issue is with the files being world-writable however, which you showed didn't happen on mga2 before the update (which is also odd and unexpected). So perhaps the update is just fine (maybe unfortunate that the files are world-readable still, but that doesn't sound like what this update was supposed to address), but it takes something else to trigger the issue? Maybe for mga2 you have to enable the UNIX domain socket transport (not the default behavior) to have the issue.
Whiteboard: MGA2TOO has_procedure feedback mga3-64-ok mga3-32-ok => MGA2TOO has_procedure mga3-64-ok mga3-32-ok
Thanks David, adding mga2 32 tested in that case.
Whiteboard: MGA2TOO has_procedure mga3-64-ok mga3-32-ok => MGA2TOO has_procedure mga3-64-ok mga3-32-ok mga2-32-ok
mga2 64 tested ok Validating Advisory & srpms in comment 0 Could sysadmin please push from 2 & 3 core/updates_testing to core/updates Thanks!
Keywords: (none) => validated_updateWhiteboard: MGA2TOO has_procedure mga3-64-ok mga3-32-ok mga2-32-ok => MGA2TOO has_procedure mga3-64-ok mga3-32-ok mga2-32-ok mga2-64-okCC: (none) => sysadmin-bugs
http://advisories.mageia.org/MGASA-2013-0169.html
Status: NEW => RESOLVEDCC: (none) => boklmResolution: (none) => FIXED
CC: boklm => (none)