The VENOM “virtual machine escape” bug – what you need to know

Thanks to Mike Wood and Andrew Ludgate of SophosLabs
for their behind-the-scenes work for this article.

Plenty of vulnerabilities have been fixed in the past week, with at least Adobe, Microsoft, Mozilla and Apple delivering dozens of critical security fixes for software that includes three of the Big Four browsers.

But none of those patches were made to sound exciting, or given funky-sounding names, so they didn’t get much media attention.

VENOM, on the other hand, has had a fair amount of coverage.

It’s not a witty name, like Heartbleed (you could bleed off data via a TLS heartbeat, so that one was an amusing play on words) or Shellshock (another pun based on the fact that the bug was some shockingly bad coding in the command shell).

VENOM is a backronym – a word that was chosen for its marketing punch and then expanded into a sentence to justify it: Virtuali[s]ed Environment Neglected Operations Manipulation.

Very briefly put, it’s a “guest escape” bug in a popular open source codebase for products that provide what’s called virtualisation, a topic that comes up fairly often in any ongoing discussion of computer security.

Virtualisation explained

Virtualisation is where you take one physical computer and make it pretend to be one or more pseudo-computers, known as virtual machines (VMs).

Inside those VMs, known as guests, you can then install a range of different operating systems and applications.

The physical computer, known as the host, acts as the overall manager of the virtual guests.

As we explained when we looked at a recent flaw in the well-known Xen virtualisation software, VMs are handy for many excellent reasons:

• For testing your software on multiple operating systems at the same time.
• For trying out new system configurations more conveniently than dedicating an entire server to each test.
• For investigating suspicious programs in a way that lets you efficiently watch what they do at a very low level.
• For sharing a huge and expensive server amongst multiple services or customers.
• For keeping spare capacity to run up an unknown number of extra server instances during busy times.

Each guest VM thinks it has a real computer all to itself, and, thanks to the virtualisation layer, can’t mess with any of the other guests.

That’s especially important in a hosting environment, where one physical server may provide virtual server instances to several different customers at the same time

For all you know, your competitor’s web portal might be running in a VM on the very same physical hardware as yours, if you both chose the same service provider.

And it’s equally important that no guest can “reach out” and fiddle with the real hardware on which the VM is running.

If a guest could make unregulated changes in another guest, or in the host itself (which controls all the other guests), that could cause a security crisis.

The VENOM problem

The VENOM bug was introduced more than a decade ago in open source software called QEMU (short for “quick emulator”), a groundbreaking project that spawned a number of commercialised virtualisation products that were derived from it.

These include KVM, Xen and VirtualBox.

Simply explained, there’s a buffer overflow in the software component that simulates floppy disk drives.

This means attackers inside any guest VM could, in theory, shovel both data and code of their own choosing out of the guest and into the memory space of the host operating system, where it might be possible to trick the host into running it.

That’s why we referred above to VENOM as a “guest escape.”

Guests aren’t supposed to be able to see or influence what’s going on in other guests, let alone on the host server, for obvious security reasons.

What to do?

If you use a virtualisation product that was derived from QEMU, check your vendor or distribution for a patch.

(VMWare and Microsoft Hyper-V are popular virtualisers that do not contain QEMU code, being independently-written proprietary products.)

You are probably thinking that very few VMs set up in the past few years will include simulated floppy drives, and that this should limit the reach of the bug.

→ I have lots of VMs for malware research, and only one of them includes a virtual floppy. That’s a DOS “PC” that I keep handy for demonstrating ancient floppy-borne malware. It doesn’t get many outings these days.

Unfortunately, according to SophosLabs, QEMU loads the buggy floppy controller code into memory even if you don’t set up a virtual floppy disk device.

So, by triggering the right system calls inside a VM, you can “tickle” the buggy code anyway, and potentially exploit the vulnerability.

According to CrowdStrike, the company that originally published details about VENOM, the same problem exists in Xen.

Even in VMs with no virtual floppy configured, Xen systems have the bug in memory, just as if you had a floppy controller card plugged into a real PC but no floppy disk attached to it.

One small saving grace about VENOM: an attacker who wants to exploit it must already have root (administrator) privileges in the guest operating system.

That’s cold comfort if you have a “naked” virtual server in a hosted server farm: you can give yourself root inside your own virtual server, and so can anyone else whose guest VM happens to be sharing the host with you at that moment.

But that’s usually not the case if you’re using a hosted software service – a content management system running on a hosted installation of WordPress, say, or a web server on a hosted version of Apache.

In that case, the service operator will be looking after the host server, the guest VMs and the software stack that underpins your data.

Neither you nor any other customer ought to have root privilege on the servers that manage your content. (And if an untrusted outsider did have root privilege, they would almost certainly be able to attack or steal your content anyway.)

Another saving grace that reduces the immediate alarm is that exploiting VENOM is not as simple as stuffing a memory buffer with executable code and waiting for it to run.

So, no in-the-wild exploits are currently known [2015-05-14T12:47Z].

The bottom line

• This is a serious vulnerability, but patches are readily available, so make sure you’ve applied them.

• Ask your cloud service providers if they use any affected products, and, if so, whether they’ve patched.

• Keep calm, and carry on with virtualisation – it’s too useful a tool to give up on.

NB. Sophos Cloud runs on AWS (Amazon Web Services). According to Amazon’s security bulletin on VENOM, “[t]here is no risk to AWS customer data or instances.”

Image of snake courtesy of Shutterstock.