How Poisonous is VENOM (CVE-2015-3456) to your Virtual Environments?

Last updated at Mon, 21 Aug 2017 15:34:36 GMT

Today CrowdStrike disclosed VENOM (Virtualized Environment Neglected Operations Manipulation) or CVE-2015-3456, a vulnerability that could allow an attacker with access to one virtual machine to compromise the host system and access the data of other virtual machines. It's been a few months since we've seen a branded and logo'd vulnerability disclosure, and the main question everyone wants to know is whether this one is worthy of the naming effort. In other words, how poisonous is VENOM really?

How does it work?

VENOM takes advantage of the floppy drive emulation code of the QEmu and Xen virtualization platforms and impacts anyone who uses QEmu or Xen hypervisors, either internally within their organization, or through a cloud hosting provider that uses this technology. Fortunately, Amazon Web Services customers are NOT affected, though many other hosting platforms are. This issue also impacts hardware appliances that use virtual machine technology to detect threats, such as the FireEye platform.

[edited to add: We've also created this Whiteboard Wednesday video to explain a bit more about VENOM.]

How easy is it to exploit?

It sounds pretty bad to say you can gain control of the host operating systems and neighboring guests, but how easy is it to do that?

As of this moment, no one has released public proof-of-concept code to demonstrate the reported bug, so we're left with some measure of speculation as to whether or not this is as "easily" exploitable as suggested. The advisory from CrowdStrike provides a solid hint of where to look to rediscover the issue:

"[the safe] buffer reset is performed immediately at the completion of processing for all FDC commands, except for two of the defined commands [which do not perform the safe buffer reset]. An attacker can send these commands and specially crafted parameter data from the guest system to the FDC to overflow the data buffer and execute arbitrary code in the context of the host's hypervisor process."

Additionally, the Xen/QEMU patch notes identify the vulnerable commands:

'During processing of certain commands such as FD_CMD_READ_ID and FD_CMD_DRIVE_SPECIFICATION_COMMAND the fifo memory access could get out of bounds leading to memory corruption'

This is a small space to go bug hunting -- at a minimum, a researcher could look at this specific set of commands accepted by the floppy disk controller (FDC) and start fuzzing arguments to reproduce this issue.

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 this 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. Of note is that even a failed exploit attempt may be useful to an attacker, in that they may able to crash the hypervisor. How failure cases are handled by QEmu and Xen is not yet known.

While Rapid7 is not actively working on an exploit for this issue, the open source Metasploit Framework has a developer community with many researchers, hackers, and hobbyists. With headline events such as this, there is more-than-usual incentive to cross that Metasploit module finish line first with a pull request of working code.

What do you need to do?

If you use QEmu or Xen internally, your vendor should be able to provide a patch. The same goes for both hosting providers and appliance vendors. If your vendor does not have a patch available, the clock is ticking on exploitation, and it is worth bothering them until they commit to a timeline. If you don't depend on QEmu or Xen for virtual machine isolation, this is probably not a big deal, and instead you may want to focus on yesterday's Patch Tuesday first.

To recap, if your organization operates the affected virtualization infrastructure for internal, trusted users, you should patch at your earliest convenience, depending on your schedule for other, more critical activities. If, on the other hand, your organization operates the affected virtualization infrastructure for external customers, you should patch immediately in order to protect your customers. If you are a customer of one of these organizations, you should be getting an update soon about the patching status for your hosted environment, and you should not be shy about asking for an ETA for a patch.

Additional resources: Whiteboard Wednesday video: The VENOM vulnerability explained