The Curious Case of the Escaping Virtual Machine

September 2nd, 2015 by

A few weeks ago, a patch was issued for the widely used Xen hypervisor to fix a massive security hole. It didn’t get as much coverage as the VENOM bug earlier in the year, but the vulnerability is similar, it allows a guest Virtual Machine to access the Host Operating System, possibly running code on it. It’s called a “VM escape” or “Guest escape” bug.

Welcome to the Virtualisation Hotel

rp_vmw-virtualization-defined.jpgA hypervisor allows you to take one physical server, and run a number of virtual servers on it. These virtual servers are sharing all the physical resources like memory, CPU and network. However, the Virtual servers are completely unaware they are not running directly on physical hardware, and are blissfully ignorant of any other guests running on the same host.

This separation is important for a number of reasons, but particularly for security. A Virtual Machine should not be able to access data in any neighbouring Virtual Machine (VM) in any circumstances. A multi-tenant environment might have VM’s running from different companies on the same host, so any intrusion is a major issue, you could possibly have competitors running VM’s in the same environment.

Each VM is effectively like a guest in a hotel, you have your own room, there might be other guests sharing the gym, the lift (or elevator if you’re American), the concierge and the restaurant, but none of them should ever be able to get into your room.
Unfortunately, the hypervisor is written in software. And (at least for now), software is written by humans. Humans aren’t perfect, and from time to time, believe it or not, they make mistakes. In software, these mistakes manifest as bugs and in some instances security holes or vulnerabilities.

The Keys to the Kingdom

venom_logoBack in May 2015, the “Venom” bug the virtual emulator for a floppy disk drive (anyone remember them?) was found to have a massive security hole, an attacker could exploit this to access the host operating system. Even if you didn’t configure a virtual machine to have a floppy drive (and why would you?), the code was still present in the guest and could be exploited. VENOM (which stands for Virtualised Environment Neglected Operations Manipulation) got a lot of press coverage at the time.

In July, Xen patched a similar vulnerability. This time, the CD-ROM emulator was the guilty party. Unlike VENOM, if you don’t have a CD-ROM configured, you are not affected. However, in order to install software from .ISO files, most VM’s are normally configured with virtual CD-ROM’s. This has not been as widely reported as its predecessor bug though.

So what are the dangers of “VM Escape” bugs? Well, in the hotel analogy, imagine if a hotel guest managed to get a key that allowed him into any guest room he wanted, and any staff areas in the hotel. Any attacker will have access to the host network, all see what’s happening in all other VM’s running on the host, effectively, the keys to the kingdom.
What can I do?

In general, the best practice is to employ a ‘defence in depth’ approach. With several layers of security, an attacker will have to negotiate several independent security controls in order to compromise your systems. This will at worst, slow down an attacker or at best, cause enough frustration for he (or she) to move on to someone else.

For the virtual environment, steps can you take will include:

  • Patch your hypervisor:  This is the only way to protect against this particular vulnerability. From experience, administrators keep Operating Systems up to date religiously in the best cases, but are more lax around the hypervisor.
  • Patch any software and Operating Systems running on virtual machines:  Just like with the hypervisor, this is crucial. Hackers can easily target systems that haven’t been patched, and they now have a list of known vulnerabilities to use to access the server.
  • Run Endpoint Security Software on the Virtual Machines:  This will pick up most malicious code trying to run on your Server, before it ‘escapes’.
  • Don’t install any software or feature you don’t need:  This reduces your attack surface. If you don’t need a CD-ROM or Floppy disk, just don’t install it. The more software you have running, the more vulnerabilities you are exposed to.

Has this Happened Before?

Yes.  A VM escape bug was reported on VMware workstation in 2008. A fully working exploit labelled Cloudburst was presented in Black Hat USA in 2009. This time, the bugs were in the emulated video adapter.

The Future

Security breaches in virtualised environments are still relatively uncharted territory, so it will be interesting to see what happens in the future. As you can imagine, this is very fertile ground for hackers and cyber criminals. The industry will have to respond at some point, but until then, administrators will need to keep on their toes.

As we move into the Software-defined world, where storage, network and a lot of IT infrastructure are moving into the virtual space, we will almost definitely see more vulnerabilities like this, and maybe even some security breaches or incidents.

Image sources: (Screenshot of video) , Virtualization illustration (Visio Stencil)

Leave a Reply

Your email address will not be published. Required fields are marked *