VENOM: QEMU vulnerability (CVE-2015-3456)
Red Hat Product Security has been made aware of a 'buffer overflow' vulnerability affecting the Floppy Disk Controller (FDC) emulation implemented in the QEMU component of the KVM/QEMU and Xen hypervisors. The vulnerability, which has been assigned CVE-2015-3456 and is now being referred to as VENOM, was discovered by Jason Geffner of CrowdStrike, Inc. The vulnerability was rated as having an Important impact.
QEMU is a generic and open source machine emulator and virtualizer and is incorporated in some Red Hat products as a foundation and hardware emulation layer for running virtual machines under the Xen and KVM/QEMU hypervisors.
A privileged guest user could use this flaw to crash the guest or, potentially, execute arbitrary code on the host with the privileges of the host's QEMU process corresponding to the guest. It needs to be noted that even if a guest does not explicitly have a virtual floppy disk configured and attached, this issue is exploitable. The problem exists in the Floppy Disk Controller, which is initialized for every x86 and x86_64 guest regardless of the configuration and cannot be removed or disabled.
There is currently no known exploit that would make use of this vulnerability. The sVirt and seccomp functionality is used to restrict host's QEMU process privileges and resource access might mitigate the impact of successful exploitation of this issue. A possible policy-based workaround is to avoid granting untrusted users administrator privileges within guests.
Detailed Impact Information
This flaw does not require the floppy device to be present in
/dev/ within the guest because the Floppy Disk Controller (FDC) is still present in the system. User-level access to a guest with sufficient permissions to talk to FDC I/O ports (i.e. the root or a privileged user on Linux or virtually any user on a Windows guest) is all that is required to exploit this flaw. To mitigate the overall risk of this vulnerability, only grant privileged guest access to trusted users.
All Red Hat products that include QEMU are vulnerable to this flaw. Affected Red Hat products are the following:
|Red Hat Enterprise Linux 5||
|Red Hat Enterprise Linux 6||
|Red Hat Enterprise Linux 7||
|Red Hat Enterprise Virtualization 3 (RHEL 6)||
|Red Hat Enterprise Virtualization 3 (RHEL 7)||
|OpenStack Platform 4 (RHEL 6)||
|OpenStack Platform 5 (RHEL 6)||
|OpenStack Platform 5 (RHEL 7)||
|OpenStack Platform 6 (RHEL 7)||
|RHEV-H 3 (RHEL 6)||
|RHEV-H 3 (RHEL 7)||
Updates for RHEL Hypervisor hosts
Errata for the
qemu-kvm-rhev packages for RHEL 6.6.z and RHEL 7.1.z have been made available; see the table above. We recommend that customers update the
qemu-kvm-rhev package on RHEL Hypervisor hosts to the latest version using the
yum package manager. See the Resolution section below for instructions.
Updates for RHEV Hypervisor (RHEV-H) hosts
RHEV-H images have been rebuilt with the fixed version of QEMU and are now available for download. See the RHSA-2015:1011 for details. Updated images for the older 3.4 version of the Hypervisor are available upon request.
As a Red Hat customer, the easiest way to check vulnerability and confirm remediation is the Red Hat Access Lab: VENOM: QEMU Vulnerability Detector.
To eliminate the possibility of exploitation, install the updated QEMU, KVM, or Xen packages that have been made available through the advisories listed in the above table.
To install the updates, use the yum package manager as follows:
To only update the QEMU package (or the relevant package for your system) and its dependencies, use, for example:
yum update qemu-kvm
Following the update, the guests (virtual machines) need to be powered off and started up again for the update to take effect. It is also possible to migrate guests away from the affected host, update the host, and then migrate the guests back. Please note that it is not enough to restart the guests because a restarted guest would continue running using the same (old, not updated) QEMU binary.
- Article Type
What is the best way to update this on a RHEV-H? I have ssh'd on but am told "Using yum is not supported" , this is running Red Hat Enterprise Virtualization Hypervisor 6.6 (20150421.0.el6ev)
There's no supported way to update packages on RHEV-H. Updated RHEV-H images have been built and are now undergoing testing. As soon as they've been made available, this article will be updated and customers notified.
ah I got confused by "We recommend that customers update the qemu-kvm-rhev package on RHEL Hypervisor hosts to the latest version using the yum package manager" which implied it could be done ;)
Ok thanks for the reply, I will roll out the updates the usual way via the images when available, thanks.
The updated RHEV-H images are now available. The article has been updated.
It's said above that "it is not enough to restart the guests because a restarted guest would continue running using the same (old, not updated) QEMU binary" does that mean the vulnerability will still remain after patching the hypervisor and rebooting the VM. If so how to resolve that.
As it says in the article: to resolve the issue, you can either power off your VMs, update QEMU, and start them up again (so that they will run with the new, patched QEMU binary), or you can migrate the VMs to another hypervisor, update the original QEMU, and migrate your VMs back.
Will the rhev-h-images be updated even for 3.4? 3.5 is still buggy and would be a high risk for our infrastructure, which depends on bonded interfaces etc.
RHEV-H 3.4 images will be made available as well. The article will be updated when they are released, and a note will be added to this discussion.
Apologies for taking so long to wrap this up.
RHEV-H 3.4 images have been made available, but the download is only per customer request. Please, open a case if you still require updated images for 3.4.
below last comment make customers confuse. This comment mean is that "Please note that it is not enough to restart the guests [[[without applying kvm patch on hypervisor]]] because", right?
"Please note that it is not enough to restart the guests because a restarted guest would continue running using the same (old, not updated) QEMU binary."
This means that guests need to be powered off and on (not only restarted) after you apply the patch. So, the procedure is as follows:
In other words, even after you update the packages, it is NOT enough to restart the guests. They need to be powered off and on. (Unless you migrate the guests to a different hypervisor, patch your original hypervisor, and then migrate the guests back.)
Thanks Rebert for clarification.