A recent security update from hypervisor company Xen fixes one of most worrying sorts of vulnerability in the world of virtualisation: guest escape.

The potential severity of a flaw of this sort has led to this one being turned into a BWAIN (Bug With An Impressive Name), with many headlines dubbing it the “Explo-Xen bunker buster.”

Stripping away the dramatic name, here’s what went wrong.

A hypervisor is a sort-of stripped down operating system that takes one physical computer and makes 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.

This is how most cloud services work, so that cloud providers don’t need to dedicate specific hardware to each customer, making the service more cost-effective and allowing it to adapt more easily to changes in load. The result, of course, is that different customers’ VMs end up running side-by-side on the same physical server.

So, the hypervisor is there, amongst other things, to maintain security amidst the illusion that each guest is running on a standalone computer of its own. Most importantly, no guest can be allowed to change the way that the physical memory of the host itself is allocated. If that were possible, a guest might be able to grab access to memory pages in use by other guests.

If your Windows VM were running next to my Linux VM, for example, and I could sneakily reallocate some of your memory to my VM, I could dig around at my leisure to see what you were up to: application settings, configuration information, even customer data might fall straight into my hands.

Worse still, if I could write into your memory pages, I might be able to implant malware, change passwords, turn off security features, and much more, thereby using a flaw in the host to sidestep the security precautions inside your own VM.

The “bunker buster”

Xen’s recent announcement, XSA-182, describes itself like this:

The PV pagetable code has fast-paths for making updates to pre-existing pagetable entries, to skip expensive re-validation in safe cases (e.g. clearing only Access/Dirty bits). The bits considered safe were too broad, and not actually safe.

Simplified and put into plain English, this means that the security checks used by the host to stop guests messing with each other’s memory didn’t always work. Full security checks were slowing things down, so a shortcut was programmed that turned out to be inadequate, introducing a loophole for attackers.

In this case, the bug wan’t just a guest-to-guest problem, but a guest-to-host bug. In other words, the guest could mess with the entire server, and thus implicitly with any other guest as well.

As far as we can tell, the bug only affects very old Intel-based server hardware, where the host server’s processor lacks some of the additional hardware protection that has been added to Intel chips in the last 10 years.

Nevertheless, we recommend that you patch!

And if you’re a programmer, be extra-cautious when you try to speed things up by cutting down on security checks.