Zero-day vulnerability found in VirtualBox

Recently a Russian researcher released the details of a zero-day vulnerability in VirtualBox that allows an attacker to exit the virtual machine to execute malicious code on the host operating system.

Russian researcher Sergey Zelenyuk discovered a zero-day vulnerability that directly affects version 5.2.20 of Virtual Box, as well as previous versions.

This vulnerability detected would allow an attacker to escape the virtual machine (guest operating system) and move to Ring 3, so that from there you can make use of existing techniques to escalate privileges and reach the host operating system (kernel or ring 0).

According to the initial details of the disclosure, the problem is present in a shared codebase of the virtualization software, available on all supported operating systems.

About the Zero-Day vulnerability detected in VirtualBox

According to a text file uploaded to GitHub, Saint Petersburg-based researcher Sergey Zelenyuk, encountered a chain of errors that may allow malicious code to escape from the VirtualBox virtual machine (the guest operating system) and runs on the underlying operating system (host).

Once outside the VirtualBox VM, the malicious code runs in the limited user space of the operating system.

"The exploit is 100% reliable," Zelenyuk said. "It means that it always or never works due to mismatched binaries or other more subtle reasons that I didn't take into account."

The Russian researcher says zero-day affects all current versions of VirtualBox, it works regardless of host or guest OS that the user is running, and is trusted against the default settings of newly created virtual machines.

Sergey Zelenyuk, in total disagreement with Oracle's response to their bug bounty program and current vulnerability "marketing," has also posted a video with the PoC showing 0-day in action against an Ubuntu virtual machine that runs inside VirtualBox on a host OS also from Ubuntu.

Zelenyuk shows details of how the bug can be exploited on configured virtual machines with "Intel PRO / 1000 MT Desktop (82540EM)" network adapter in NAT mode. It is the default setting for all guest systems to access external networks.

How the vulnerability works

According to the technical guide made by Zelenyuk, the network adapter is vulnerable, allowing an attacker with root privilege / admin to escape to host ring 3. Then, using existing techniques, the attacker can escalate Ring privileges - via / dev / vboxdrv.

«The [Intel PRO / 1000 MT Desktop (82540EM)] has a vulnerability that allows an attacker with administrator / root privileges on a guest to escape to a host ring3. Then the attacker can use existing techniques to increase privileges to call 0 via / dev / vboxdrv, ”Zelenyuk describes in his whitepaper Tuesday.

zelenyuk says an important aspect of understanding how the vulnerability works is understanding that handles are processed before data descriptors.

The researcher describes the mechanisms behind the security flaw in detail, showing how to trigger the conditions necessary to obtain a buffer overflow that could be abused to escape the confinements of the virtual operating system.

First, it caused an integer underflow condition by using packet descriptors - data segments that allow the network adapter to trace network packet data in system memory.

This state was exploited to read data from the guest operating system into a heap buffer and cause an overflow condition that could lead to function pointers being overwritten; or to cause a stack overflow condition.

The expert suggests that users mitigate the problem by changing the network card in their virtual machines to AMD PCnet or a paravirtualized network adapter or by avoiding the use of NAT.

“Until the patched VirtualBox build is out, you can change your virtual machines' network card to PCnet (either) or Paravirtualized Network.