Since the early days of virtualization, people have theorized about the capability of an “escape the VM” type of attack. This is a hacker’s nirvana: to take over a running virtual guest and use it as a base from which to attack the underlying virtual host.

The Cloudburst vulnerability was discovered by Core Security Technologies in 2008. Armageddon was declared, and people began saying this was the end of the line for virtualization. Once the fervor settled, it was found that Cloudburst only worked against versions 6.02 and 5.5.4 of VMware Workstation: not exactly earthshattering.

The next major security vulnerability was Heartbleed. While not an “escape the VM” attack, but a security bug in OpenSSL, Heartbleed was an issue for the majority of virtualization vendors, all of whom used OpenSSL for their security layer. After the storm settled and the exploit was patched, calm returned to the fold.

Yesterday in a blast of media outrage, we were presented with VENOM (CVE-2015-3456), or to give it its full Sunday name (you know, the one you only get called by your mother when you’ve been naughty), Virtualized Environment Neglected Operations Manipulation. It’s time to cue the hysteria flood from the mainstream tech press and prepare for sensationalist stories of apocalyptic magnitude! To quote CrowdStrike, the company that discovered the threat:

“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.”

What Exactly Is VENOM, and Should I Run to My Bunker?

Two of the most numerous virtualization platforms by revenue, ESXi and Hyper-V, are immune. That is correct: they are immune.

Now, let us look at what is affected:

This bug is in QEMU’s virtual floppy disk controller. You read that correctly: the virtual floppy disk controller is the avenue for the vulnerability. The biggest issue here is that, whereas other exploits required some esoteric configuration to be accessible, the virtual floppy disk controller is a standard configuration for the majority of VMs. The default configuration for a virtual guest is to have a floppy disk attached to it, and it takes a conscious act to remove it before you move to building your machine. So, theoretically, there may be millions of attackable guests in this situation.

But let’s stop here for a minute. The bug is in QEMU’s controller. This means that ESXi and Hyper-V are immune, since they don’t use QEMU’s controller. That’s great—no need to head for the bunker and eat hard biscuits and drink filtered water for the rest of my life. Still, the impact could be far-reaching: Rackspace, AWS, Xen, and any Linux distribution that uses KVM are potentially vulnerable. Nearly every Linux distribution in the enterprise uses KVM, so this could mean a lot of appliances are vulnerable.

That said, when the news broke, AWS quickly announced that its platforms were not vulnerable to the exploit. The major Linux vendors have rapidly released patches and advisories to cover their positions.

Cloudstrike’s press release was balanced. It mentioned that Hyper-V and VMware weren’t impacted and noted that there were no known attacks in the wild using the exploit. However, this was not the case with the general tech press, which would lead you to think that Johnny Blackhat was wandering freely around your management network, stealing your personal data with impunity. This really is not the case. Yes, news of the exploit needed to be propagated to the general public, and those who administer these environments need to know about the patches and security, but this sensationalism in exploit reporting really needs to stop.

Is VENOM in the Wild?

There have been no reported cases of VENOM being exploited in the wild. Most of the commentary has been about the press reaction to a low-volume attack. The potential is great, but no one has stepped forward to say they have a working exploit. Let us look into that for a bit as well.

To make use of this exploit, you need to first exploit the virtual machine. That is far easier to do than to attack the hypervisor. Why? Because the virtual machines run our workloads, and workloads get attacked far more often than anything else. Just like physical systems running workloads, the vulnerabilities in application code, operating systems, networks, and the like are much easier to manipulate. As an attacker, if I can get your data by doing a simpler attack, I will. Therefore, a good compensating control for any “escape the VM” attack is to lock down and harden your operating systems, improve your authentication and authorization controls, harden the applications, and of course, create secure code.

Now, if they can expose this attack, where will the attackers end up? There have been several attacks of this nature within peripheral devices. All of these attacks end up within the virtual machine manager, a black box that acts as a jail surrounding the guest operating system. On a Type 2 hypervisor such as VMware Workstation, QEMU (direct use), or VirtualBox, you will end up in the original operating system. This is one reason why, on a Type 2 hypervisor, you must harden your operating system. It’s also why we consider Type 2 hypervisors less secure. On a Type 1 hypervisor such as vSphere, Xen, KVM, and Hyper-V, the exploit will land you inside the virtual machine manager jail for the attacked VM. The real trick is to somehow break out of that jail and end up below it, in the real hypervisor.

Closing Thoughts

There is quite a bit of code within a virtual machine these days. Much of it is historical, and much of it can be removed as we no longer use floppy devices for much. However, historically they are there for convenience and backwards compatibility. Old code should always be inspected for some form of attack. The only real solution to an “escape the VM” attack, or really any style of attack, is to develop an holistic view of security. Practice defense in depth and use compensating controls with appropriate monitoring. Should you have thought about VENOM before it happened? Yes, nearly every “escape the VM” I’ve ever have heard about attacks a legacy peripheral device that is no longer in use or kept up to date. For QEMU-based hypervisors, perhaps the solution is to employ SELinux or an equivalent in a broader way, denying access to those peripherals while at the same time disabling the devices so they cannot be seen.

Just patching and forgetting will not prevent these types of attacks in the future, so think about your mitigation steps now, and develop a plan for the future. Sometimes an attack is just hype, but in other cases it’s a real issue. Happily, with no cases reported in the wild, VENOM has turned out to be venomless.