Exploiting Hyper-V: How We Discovered MS13-092

During a recent research project we performed an in-depth security assessment of Microsoft’s virtualization technologies, including Hyper-V and Azure. While we already had experience in discovering security vulnerabilities in other virtual environments (e.g. here and here), this was our first research project on the Microsoft virtualization stack and we took care to use a structured evaluation strategy to cover all potential attack vectors.
Part of our research concentrated on the Hyper-V hypervisor itself and we discovered a critical vulnerability which can be exploited by an unprivileged virtual machine to crash the hypervisor and potentially compromise other virtual machines on the same physical host. This bug was recently patched, see MS13-092 and our corresponding post.

In this post, we will focus on the DoS vulnerability, which is rated as important and can affect the availability of the complete hypervisor and potentially all cloud environments based on Hyper-V technology. We think that a skilled and motivated attacker can discover and exploit the vulnerability within two to four weeks without the need for non-public knowledge (or a specific window of opportunity).
Due to the close relationship between the Hyper-V and Azure hypervisor and the fundamental nature of the exploit, we assume that our Proof-of-Concept code will affect the Azure Cloud environment as well. As MS13-092 is an official Microsoft Security Bulletin, we furthermore assume that the vulnerability is patched in Azure in the meantime.
The bug itself is caused by a mishandling of an error condition and was discovered rather fast after the initial setup of our lab environment: Hyper-V partitions can communicate with the hypervisor using so called hypercalls. They work similar to system calls that are used to communicate between ring 3 and 0 but operate between ring 0D (“guest-ring-0”) and 0P (“hypervisor-ring-0”) instead. The actual implementation differs between AMD and Intel systems but the overall interface is the same.
For Intel systems, the vmcall instruction is used to execute a hypercall. Register rcx stores the hypercall number, rdx and r8 contain the guest physical address (GPA) of supplied input and output parameters (we ignore the so-called fast calling convention for now). On the hypervisor side, multiple checks are performed before the hypercall handler is executed. This includes a check if the request originates from Ring 0 (no such restriction is enforced by Intel. The vmcall instruction can also be executed from user mode from an unprivileged partition (read: typical virtual machine), if all supplied memory addresses are properly aligned. In addition the user supplied input GPA is checked against an upper boundary as illustrated in the next image:

If this check fails, the code continues through an error handling function and finally lands in the function at hv+0x2B42DC. This sub function uses the user controlled input address (now stored in rax) directly for a memory read as shown below:

Here, by choosing the right value for our input address we can trigger an invalid memory read and crash the hypervisor itself, resulting in the infamous BSOD.
We think this bug is an interesting example for the kind of issues that can compromise the security and availability assumptions that many users might have with regard to their hypervisors and virtualized environments. We will release our PoC, further detail on the (even more interesting) privilege escalation part and additional Hyper-V research at our Troopers 14 talk. Furthermore the bug will be discussed in much more detail in our Exploting Hypervisors workshop at Troopers.

Stay tuned,
Felix & Matthias