In recent days, much has been said and written around the recently disclosed “Venom” vulnerability. It is important to fully understand the real-world severity of vulnerabilities such as Venom. Although the threat is potentially severe and certainly interesting (it is in a class of relatively rare guest escapes from virtual machines), one has to take into account the existing attack surface, mitigation, and other factors. In other words, “exposure” must be taken into account when discussing this (or any) vulnerability or attack.
The Venom vulnerability refers to a flaw in the QEMU FDC (floppy disk controller), which is enabled in the default configuration of Xen and KVM virtualization platforms. QEMU is an open-source package with widespread adoption, the scope of which is not fully quantifiable. This vulnerability can be triggered even in configurations in which a floppy device is not present or configured. The flaw potentially allows an attacker to “escape” a guest virtual machine host and gain access to and control of the physical host. This is a privilege escalation vulnerability. In a virtualized environment where the guest can escape to the host, this threat takes on a greater impact. In a successful exploitation, the attack could potentially execute arbitrary code on the underlying host, read and monitor memory contents (exposing sensitive data from guest VMs), or invoke a denial of service on the host (again, affecting all guests).
An attacker must have local/authenticated root access to a guest VM. Now, this could take on many forms. This can be achieved directly if the attacker, for example, establishes his own “cloud-based” VM instance and directly runs exploit code in that instance. It can also, potentially, be done indirectly if the attacker entices a user on a cloud-based VM instance to execute malicious code via a drive-by download or similar method. Limited proof-of-concept exploit code has been released, but it is limited in function and execution and does not trigger and exploit this scenario in all expected conditions. We have yet to see (as of this writing) any additional exploit attempts, or in-the-wild malware-based exploitation.
This is where we have to think about existing surface, mitigation, and other factors that come into play. Amazon (AWS) and several other services have released statements saying that they are not vulnerable. Other providers (such as Digital Ocean and RackSpace) have released statements regarding their patching process (most of which appear to be complete) and any remaining actions that need to be taken by users. So because this flaw was handled responsibly and affected vendors were given time to react, a great deal of mitigation has already taken place–greatly minimizing the exposed attack surface.
Patches are available from Xen, QEMU, and others that use the affected technology.
- Xen: http://xenbits.xen.org/xsa/advisory-133.html
- QEMU: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e907746266721f305d67bc0718795fedee2e824c
Intel Security and McAfee Labs will continue to analyze this threat and provide updates to this blog as new details emerge.