Hyper-V bug that could crash 'big portions of Azure cloud infrastructure': Code published
- Reference: 1622636046
- News link: https://www.theregister.co.uk/2021/06/02/hyperv_bug_that_until_recently/
- Source link:
A fundamental principle of virtualization is that the virtual machine guests are isolated from the host server and from one another. Vulnerabilities that breach this barrier are particularly serious for hosting companies, since they raise the possibility of one customer seeing data that belongs to another, or criminal intrusions into the hosting company's infrastructure.
This issue, [1]CVE-2021-28476 , was patched by Microsoft on May 11.
You little BSOD
Microsoft said it "allows a guest VM to force the Hyper-V host's kernel to read from an arbitrary, potentially invalid address. The contents of the address read would not be returned to the guest VM."
It continued: "In most circumstances, this would result in a denial of service of the Hyper-V host (bugcheck) due to reading an unmapped address. It is possible to read from a memory mapped device register corresponding to a hardware device attached to the Hyper-V host which may trigger additional, hardware device specific side effects that could compromise the Hyper-V host's security."
[2]
Proof of concept exploit for crashing a Hyper-V host from the guest
A bugcheck, also known as a blue screen of death, crashes the host. This meant that anyone with a VM on Azure would have been able to crash one of Microsoft's servers, though normally that is the limit of the damage. In theory this could escalate to remote code execution on the server, but this is unlikely since it relies on knowledge of the address of a memory-mapped device. The vulnerability is nevertheless critical.
Security researcher Axel Souchet, who maintains a blog called [3]Diary of a reverse-engineer , has now posted [4]proof of concept code which enables anyone to blue-screen an unpatched Hyper-V host via code running in the guest.
[5]
"The bug itself happens in VmsIfrInfoParams_OID_SWITCH_NIC_REQUEST which is a function that can be called with attacker-controlled data (which it shouldn't) and dereference twice a pointer (boom->_win below) that a malicious guest virtual machine can provide," said Souchet.
[6]
[7]
4 stories
[8]Microsoft emits more fixes for Exchange Server plus patches for remote-code exec holes in HTTP stack, Visual Studio
[9]Penguin takeover: We tried running some GUI Linux apps on Windows the official way – and nothing exploded
[10]What's in Fedora 34? GNOME 40, accelerated Wayland, PipeWire Audio, improved Flatpak support, and more
[11]The first rule of ERP? Don't talk about ERP: App-maker IFS reckons market has moved on
Users cannot just remote desktop into a Windows VM and run some code: the posted exploit requires Ubuntu Focal and a kernel rebuild.
Discovery
The issue was discovered by researchers Leo Adrien and Daniel Fenandez at Blue Frost Security, Peleg Hadar of SafeBreach Labs, and Ophir Harpaz at Gardicore Labs. Hadar and Harpaz are presenting a session at the forthcoming Blackhat USA conference about how the bug was [12]discovered using fuzzing tools specially adapted for Hyper-V. The presenters said they promise "a live demo of exploiting this vulnerability, which until only a few weeks ago could take down big portions of Azure cloud infrastructure."
While Microsoft will presumably have been quick to patch Azure, the same may not be true of other Hyper-V installations. Hosting companies are the most vulnerable since any customer may run up a virtual machine, though most hosting providers run Linux-based hypervisors. Enterprise installations accessed only by trusted employees are less at risk, though it still is a critical vulnerability and should be patched as soon as possible if it has not already been done.®
Get our [13]Tech Resources
[1] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-28476
[2] https://regmedia.co.uk/2021/06/02/public_domain_hyperv_poc.jpg
[3] https://doar-e.github.io/
[4] https://github.com/0vercl0k/CVE-2021-28476
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/virtualization&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YLerIaBpx4zDyfoPj0ITYgAAAFQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/virtualization&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YLerIaBpx4zDyfoPj0ITYgAAAFQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/virtualization&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YLerIaBpx4zDyfoPj0ITYgAAAFQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2021/05/11/microsoft_patch_tuesday_exchange_hyperv/
[9] https://www.theregister.com/2021/04/23/wslg_first_look/
[10] https://www.theregister.com/2021/03/17/fedora_34_preview/
[11] https://www.theregister.com/2021/03/11/ifs_cloud/
[12] https://www.blackhat.com/us-21/briefings/schedule/index.html#hafl-our-journey-of-fuzzing-hyper-v-and-discovering-a--day-23498
[13] https://whitepapers.theregister.com/
Distribute links? How about print it out, laminate it, then super glue it to the wall of the staff break room.
Anonymously, of course.
Because all the on-premises software is entirely bug free? Quite an impressive achievement if so.
Nice strawman fallacy
All on-premises software / systems aren't publicly available to use by anyone to do with what they like. Defense in depth is possible. Or do you / would you allow random people to create VMs, containers, run processes on your internal private systems?
On the flip side, where do you think this vulnerability is likely to have been patched first - on-prem Hyper V or Azure?
Where would it likely be exploited first on prem, private system, or a publicly available system?
When you are on-premises, you can deploy other measures to protect access to your vms. On The Cloud, you can only protect your own vms, not those of other customers on the same physical host.
The company I work for is moving everything to Azure because it's way more reliable, secure and cheaper to do this than to run some machines in house.
Am I allowed to distribute links to this article?