Share this story

There's an extremely critical bug in the Xen, KVM, and native QEMU virtual machine platforms and appliances that makes it possible for attackers to break out of protected guest environments and take full control of the operating system hosting them, security researchers warned Wednesday.

The vulnerability is serious because it pierces a key protection that many cloud service providers use to segregate one customer's data from another's. If attackers with access to one virtualized environment can escape to the underlying operating system, they could potentially access all other virtual environments. In the process, they would be undermining one of the fundamental guarantees of virtual machines. Compounding the severity, the vulnerability resides in a low-level disk controller, allowing it to be exploited when guest or host OSes alike run Linux, Windows, Mac OS X, or possibly other OSes. Researchers from security firm CrowdStrike, who first warned of the vulnerability, wrote:

Most VM escape vulnerabilities discovered in the past were only exploitable in non-default configurations or in configurations that wouldn’t be used in secured environments. Other VM escape vulnerabilities only applied to a single virtualization platform, or didn’t directly allow for arbitrary code execution.

VENOM (CVE-2015-3456) is unique in that it applies to a wide array of virtualization platforms, works on default configurations, and allows for direct arbitrary code execution.

The vulnerability is the result of a buffer-overflow bug in QEMU's virtual Floppy Disk Controller, which is used in a variety of virtualization platforms and appliances. It is known to affect Xen, KVM, and the native QEMU client software, and it may affect others. VMware, Microsoft Hyper-V, and Bochs hypervisors are not affected. At publication time, patches were available from the Xen Project and the QEMU Project. RedHat has a patch here. There are also workarounds users can follow to lessen the risk of exploitation. The vulnerability is serious enough that users of other virtualization packages should immediately contact the developers to find out if they're susceptible. The bug has existed since 2004.

There's no indication that the vulnerability is being actively exploited maliciously in the wild. Although the vulnerability is agnostic of the OS running both the guest and host, attack code exploiting the bug must have administrative or root privileges to the guest. The threat is greatest for people who rely on virtual private servers, which allow service providers to host multiple operating systems on a single physical server. Because virtual servers are often provided to different customers, it's common that they have administrative or root privileges to that guest OS that could be used to take over the underlying machine.

CrowdStrike's advisory went on to state:

VENOM, CVE-2015-3456, is a security vulnerability in the virtual floppy drive code used by many computer virtualization platforms. This vulnerability may allow an attacker to escape from the confines of an affected virtual machine (VM) guest and potentially obtain code-execution access to the host. Absent mitigation, this VM escape could open access to the host system and all other VMs running on that host, potentially giving adversaries significant elevated access to the host’s local network and adjacent systems.

Exploitation of the VENOM vulnerability can expose access to corporate intellectual property (IP), in addition to sensitive and personally identifiable information (PII), potentially impacting the thousands of organizations and millions of end users that rely on affected VMs for the allocation of shared computing resources, as well as connectivity, storage, security, and privacy.

For those who are unable to patch vulnerable software, CrowdStrike offered the following:

Running Virtual Machine hypervisors in certain configurations will minimize or even completely eliminate the impact of this vulnerability. The following is not an exhaustive list of such configurations and we welcome additional suggestions:

Xen

Xen systems running x86 paravirtualized guests are not vulnerable to this exploit

ARM systems are not vulnerable

Enabling stub-domains will mitigate this issue, by reducing the escalation to only those privileges accorded to the service domain. qemu-dm stub-domains are only available with the traditional “qemu-xen” version.

Further Reading

The vulnerability has been dubbed Venom, short for virtualized environment neglected operations manipulation. Some people are already comparing its severity to Heartbleed, the catastrophic bug disclosed in April 2014 that exposed private cryptography keys, end-user passwords, and other sensitive data belonging to countless services that used the OpenSSL crypto library. At this early stage, it's too early to know if the comparison to Heartbleed is exaggerated, since at the moment there's no indication that Venom is being actively exploited.

Tod Beardsley, a research manager at vulnerability assessment provider Rapid7, has indicated that the threat from Venom is likely not as serious. In an e-mailed statement, he wrote:

The people most affected by VENOM are those who run hosted VPS services (and therefore, do routinely give root access to strangers' guest machines), and those who subscribe to the same VPS services. Customers of VPS services should pester their vendors until patches are applied, and the vendors should move on this rapidly.

So, given this barrier to entry, how "easy" is it to exploit VENOM and gain control of the host operating systems and neighboring guests? As of this moment, no one has released public proof of concept code to demonstrate the reported VENOM bug, so we're left with some measure of speculation as to whether or not this is as "easily" exploitable."

It's important to note that while this vulnerability is technically local-only, successful exploitation leads to breaking out of a guest OS to the host OS. This circumstance leads me to believe that VENOM is an "interesting" bug to the sorts of people who do exploit research for a living. To be able to break out of a guest OS to a host OS is a rare and powerful ability, and such bugs are uncommon. Given this incentive of interestingness, I would expect to see a public proof of concept exploit appear sooner rather than later.

Those limitations aside, there's an extremely broad range of platforms that are vulnerable to this exploit, and those platforms house servers used by banks, e-commerce providers, and countless other sensitive services. Given the large number of servers that are vulnerable and the extremely high value of the assets they contain, this security bug should be considered a top priority.