The Xen Project, which oversees the open source Xen hypervisor, yesterday patched a seven-year-old vulnerability that allows an attacker to escape a guest virtual machine and attack the host operating system.
The flaw is so bad that the developers of the Qubes OS Project, a security-heavy operating system whose protections rely on virtualization to compartmentalize security, called it probably the worst they’ve seen in the Xen hypervisor. Ever.
“It gives any paravirtualized VM complete control over the system, reliably (no guessing, no race conditions etc),” said Marek Marczykowski-Górecki, a senior system developer at Invisible Things Lab, a security research firm and a core Qubes developer. “In Qubes OS (and probably most of Xen use cases) all Linux VMs are paravirtualized.”
Paravirtualization is a virtualization technique developed by the Xen Project that optimizes performance among other capabilities.
VM escapes are absolutely the holy grail of attacks against virtualized infrastructure. They’re especially risk in hosted environments where such an attack could be a gateway to other virtual machines running on the same commodity hardware.
Xen said in its advisory that Xen 3.4 and later are vulnerable on x86 systems only, and only paravirtualized guests on either 32- or 64-bit systems can exploit the bug.
From the Xen advisory:
“The code to validate level 2 page table entries is bypassed when certain conditions are satisfied. This means that a PV guest can create writeable mappings using super page mappings. Such writeable mappings can violate Xen intended invariants for pages which Xen is supposed to keep read-only. This is possible even if the “allowsuperpage” command line option is not used.”
“The above is a political way of stating the bug is a very critical one. Probably the worst we have seen affecting the Xen hypervisor, ever. Sadly,” Qubes wrote in its advisory.
Marczykowski-Górecki said that a skilled system-level exploit writer using available information about the vulnerability could craft an attack in a matter of hours.
“First attacker needs to be able to execute code at VM kernel level (easily possible having root access and we don’t believe user/root is meaningful separation in such complex, monolithic system as Linux),” Marczykowski-Górecki said. “When that happens, attacker can in practice access any memory page – so for example read memory of other VMs, replace its code, or even modify Xen hypervisor itself. Generally execute whatever he/she wants on the system.”
The Qubes team was especially harsh in its advisory in criticizing the fact that such a severe vulnerability went unnoticed by the Xen security team for seven years. And since security-conscious projects such as Qubes are so heavily reliant on Xen, the incident forced the developers to call into question the Xen’s commitment to security.
“The bugs in Xen are being found regularly, and this is [not] good news,” the Qubes advisory said. “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.”
This is, in fact, the second VM escape Xen has patched since July when it addressed a vulnerability in the QEMU open source machine emulator that ships with the Xen hypervisor. The vulnerability was a heap overflow happening because of the way a QEMU subsystem handles certain commands. An attacker exploiting that bug could execute code on the host with elevated privileges.
