Two security researchers who found a critical (CVSS 9.9) bug in a core component of the underlying virtualisation technology for Azure say it was in production for over a year and could have been used to "take down whole regions of the cloud". With a more complex exploitation chain, it also gave remote code execution (RCE).
Guardicore’s Ophir Harpaz and SafeBreach’s Peleg Hadar found the bug (CVE-2021-28476) in Hyper-V’s virtual network switch driver vmswitch.sys using an adapted version of the kAFL fuzzer dubbed hAFL1, and modified to support more efficient hypervisor fuzzing. (Crudely, an automated way of sending semi-random data/intentionally invalid data to a programme to trigger a fault that can then be further exploited.)
See also: 6 free 'enterprise ready' cybersecurity tools to have on your radar
The critical Hyper-V vulnerability let the two trigger denial of service (DoS) from an Azure VM that could crash major parts of Azure’s infrastructure and take down all VMs that share the same host, a blog by the two detailed today, adding that "with a more complex exploitation chain, the vulnerability can grant the attacker remote code execution capabilities. These, in turn, render the attacker omnipotent; with control over the host and all VMs running on top of it, the attacker can access personal information stored on these machines, run malicious payloads, etc."
The two reported the Hyper-V vulnerability in late March 2021, Microsoft patched it in early May.
Where was the critical Hyper-V vulnerability?
The security flaw first appeared in a build from August 2019, suggesting that the bug was in production for more than a year and half, Harpaz and Hadar said on July 28. It affected Windows 7, 8.1 and 10 and Windows Server 2008, 2012, 2016 and 2019.
The bug is essentially an arbitrary read vulnerability in how vmswitch, Hyper-V’s virtual switch handles object identifier (OID) requests -- which might include hardware offloading, Internet Protocol security (IPsec) and single root I/O virtualization (SR-IOV) requests.
Follow The Stack on LinkedIn
The two described it as the "combination of a hypervisor bug - an arbitrary pointer dereference - with a design flaw allowing a too-permissive communication channel between the guest and the host" (technical write-up here) and noted that it "demonstrates the risks that a shared resource model (e.g. a public cloud) brings. Indeed, in cases of shared infrastructures, even simple bugs can lead to devastating results."
Bugs are often found almost by accident (see, for example, #HiveNightmare). This was a more targeted find. Guardicore's Harpaz told The Stack: "We knew from the start that we were targeting Hyper-V. It was also quite clear to us that the virtual switch was the most prominent target, as it is a large binary with a lot of code, and is responsible for surprisingly many networking capabilities in Hyper-V.
"Our fuzzer, like any other fuzzer, made it possible to automate the bug-hunting process. Without it, we would have to manually search for bugs in this huge codebase, which is unpleasant (to say the least). Such an approach could have taken more than a year (we spent a couple of months on the whole research).
Asked how challenging getting RCE was, she added: "The RCE is obtained if the attacker can get the Hyper-V host to read directly from a hardware device. Such read operation can (sometimes) trigger code execution. This is a non-trivial exploitation process but it's possible according to MSRC, which is also what gave it the CVSS score of 9.9 (out of 10).
Guardicore's team are particularly proud of hAFL1's role in identifying the 0day.
The fuzzer's novel approach is that it sends "fuzzing inputs from the host level", Harpaz will explain at a Black Hat talk in August, detailing how it mimics a child-partition by initializing necessary data structures in vmswitch and sending inputs to the target as if it were over VMBus: "By doing that, hAFL1 leverages Intel-PT to obtain coverage feedback. hAFL1 allows structure-aware fuzzing of RNDIS packets, and also provides detailed crash reports."
Microsoft had not responded to a request for comment as we published.
