Xen Patches 'Worst'-Ever Virtual Machine Escape Vulnerability

One of the fundamental assumptions in virtualized computing environments is that code running in one virtual machine cannot escape its confines and directly access the host operating system and thereby other VMs running on the same physical server. Any vulnerability that enables a VM escape is considered a pretty big deal.

So news this week that a bug of precisely this nature had remained undetected for seven years in the popular Xen hypervisor is sure to prompt questions about the open source project’s security practices.

In an advisory issued yesterday, the Xen Project described the now patched vulnerability as one that could allow the administrator of a guest VM to escalate privileges and take complete control of the host system. The vulnerability gives attackers a way to bypass a mechanism in the Xen hypervisor that is designed to prevent guest VMs from making certain changes to table entries.

“The code to validate level 2 page table entries is bypassed when certain conditions are satisfied,” the Xen advisory noted. “This means that a  [guest VM] can create writeable mappings using super page mappings,” the alert said referring to a virtual memory management capability.

The issue is somewhat mitigated in situations where the host system, rather than a guest administrator, controls the guest VM, the alert noted. However, even here, it is possible for an untrusted guest administrator to trigger the flaw unless other measures are taken to prevent the guest VM from loading code into the kernel, the Xen security advisory warned.

Versions of Xen 3.4 and higher running on Intel x86 hardware are vulnerable to the flaw. Virtual machines hosted on ARM hardware are not susceptible to the threat. In addition, only guest VMs can exploit the vulnerability, Xen said.

The Xen alert attributed the discovery of the flaw to a researcher from Alibaba but provided no details on when the problem was first reported. The issue can be resolved by applying the patch publicly released this week, Xen said.

A researcher at the Qubes OS Project described the flaw as one the “worst” ever affecting Xen.  Qubes relies on Xen’s virtualization technology to implement what it describes as a security by isolation approach to OS security. Basically, the Qubes operating system is designed to let users compartmentalize their various activities, like Web browsing and banking, into separate VMs on the same machine so as to contain and limit the fallout from an attack.

“It is really shocking that such a bug has been lurking in the core of the hypervisor for so many years,” Marek Marczykowski, senior system developer at Invisible Things Lab, the developer of Qubes OS, said in a security bulletin. “In our opinion, the Xen project should rethink their coding guidelines and try to come up with practices and perhaps additional mechanisms that would not let similar flaws plague the hypervisor ever again.”

Without such mechanisms, the Xen hypervisor makes little sense to organizations that would like to use it for security sensitive tasks, Marczykowski wrote. Given the critical nature of the Xen bug, Qubes developers have uploaded the patches directly to the current code repository instead of putting them through the usual one-week patch testing process, he said.

It's not the first time that the Xen hypervisor has been the focus of unfavorable attention over security flaws. Last October, for instance, Xen disclosed a bug that affected Amazon, Rackspace, and other cloud service providers. Earlier this year, the open source project disclosed another bug in a CD-ROM driver emulation feature that also enabled a VM escape.

The number of bugs being found in Xen is worrisome, according to Marczykowski. “For a type-1 hypervisor of the age and maturity of Xen, this simply should not be happening. If it does, it suggests the development process is not prioritizing security.”