In the course of a current virtualization research project, I was reviewing a lot of documentation on hypervisor security. While “hypervisor security” is a very wide field, hypervisor breakouts are usually one of the most (intensely) discussed topics. I don’t want to go down the road of rating the risk of hypervisor breakouts and giving appropriate recommendations (even though we do this on a regular base which, surprisingly often, leads to almost religious debates. I know I say this way too often:I’ll cover this topic in a future post ;)), but share a few observations of analyzing well-known examples of vulnerabilities that led to guest-to-host-escape scenarios. The following table provides an overview of the vulnerabilities in question:
| Year | Name | Description |
|---|---|---|
| 2007 | vmftp | Directory traversal vulnerability in VMware tools. |
| 2009 | XEN Ownage Trilogy | Exploiting drivers using DMA (mitigated by hardware virtualization support in the meantime) |
| 2009 | VMware Cloudburst | Abusing a lack of access control in a VMware 3D graphics driver. |
| 2011 | KVM Virtunoid | Dangling pointers due to a bug in the hardware emulation layer. |
| 2012 | VMware VMSA-2012-0009 | a) Bug in the Backdoor API (for communication between VMware tools and host) channel between VM and host b) Bug in the SCSI device registration (no further details available, potentially bug in hardware emulation layer) c) Buffer overflow in floppy driver (no further details available, potentially bug in hardware emulation layer) |
| 2012 | VMDK Has Left The Building | Design flaw in the VMware ESXi hard disk handling. |
| 2012 | XEN Sysret | Paravirtualization API design flaw. |
The first remarkable thing that comes to mind while analyzing the different vulnerabilities is the high number of vulnerabilities in functions not being part of the core hypervisor functionality. The basic hypervisor functionality — such as resource scheduling and isolation — was only targeted in the XEN ownage trilogy and in VMSA-2012-0009 – which also happen to be the two vulnerabilities without publicly available PoC code (PoC code for privilege escalation within the guest system, not the breakout scenario, is available for VMSA-2012-009.a though).
Secondly, the only major hypervisor that did not suffer from a breakout vulnerability yet is Microsoft Hyper-V (and, thinking of more basic hypervisors, IBM LPARs). While Hyper-V is strongly dependent on management functionality provided by a Windows server instance, the only (publicly known, at least ;-)) vulnerability in the hypervisor functionality was a Denial-of-Service vulnerability – in a driver used for paravirtualization.
Obviously one must be careful to draw conclusions from a data set that sparse, but amongst those the following might be included:
- Microsoft may have some experience in hardening low-level operating system code and probably learned some lessons for the hardening of IPC interfaces (in a very loose way, one may compare paravirtualization interfaces to IPC interfaces [where guests are processes], and I think Microsoft may have learned some lessons from RPC incidents in the past 😉 )
- Additional functionality (read: APIs/interfaces) increases complexity and complexity kills security. Nothing new so far… 😉 We’re also planning (since a longer time than I’m proud to admit) to compile a short trailer of action movies scenes where interfaces (in the broadest sense, think of transfer points in prisons) are exploited to gain/elevate access – in order to illustrate the face that a very high number of security problems arise from interfaces.
- If I would have to do research on hypervisor breakouts, I would focus on additional interfaces/functionality first.
Have a good one & stay tuned,
Matthias