VirtualBox Zero-Day Vulnerability Details and Exploit Are Publicly Available

A Russian vulnerability researcher and exploit developer has published detailed information about a zero-day vulnerability in VirtualBox. His explanations include step-by-step instructions for exploiting the bug.

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

Exploiting the vulnerability allows an attacker to escape the virtual environment of the guest machine and reach the Ring 3 privilege layer, used for running code from most user programs, with the least privileges.

Turning one "overflow" into another

Sergey Zelenyuk found that the security bug can be leveraged on virtual machines configured with the Intel PRO/1000 MT Desktop (82540EM) network adapter in Network Address Translation (NAT) mode, the default setup that allows the guest system to access external networks.

"The [Intel PRO/1000 MT Desktop (82540EM)] has a vulnerability allowing an attacker with root/administrator privileges in a guest to escape to a host ring3. Then the attacker can use existing techniques to escalate privileges to ring 0 via /dev/vboxdrv," Zelenyuk writes in a technical write-up on Tuesday.

Zelenyuk says that an important aspect in getting how the vulnerability works is to understand that context descriptors are processed before data descriptors.

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

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

This state was then leveraged to read data from the guest OS to into a heap buffer and cause an overflow condition that could lead to overwriting function pointers; or to cause a stack overflow condition.

100% reliable exploit

The exploit Zelenyuk wrote relies on the two overflow conditions. Since it provides access to Ring 3 level of permissions, privilege escalation is needed to take control over the host operating system.

Although this is not impossible, an attacker has to chain another vulnerability that would grant them increased privileges on the system.

The steps described by the researcher for exploiting the zero-day he uncovered in VirtualBox are definitely not script-kiddie-friendly as they require more advanced technical knowledge.

Buffer overflows are not always stable and most of the times they result in crashing the target. However, Zelenyuk says that his exploit is "100% reliable," and it "it either works always or never because of mismatched binaries or other, more subtle reasons I didn't account."

He tested his work on Ubuntu 16.04 and 18.04, both 86- and 64-bit with the default configuration. Proof of the success is the following video that shows the exploit running in the guest OS and executing a shell on the host OS:

This is not the researcher's first vulnerability disclosure in VirtualBox. Earlier this year, he reported another security bug in VirtualBox. It was reported responsibly for version 5.2.10 of the software. For some reason, though, Oracle fixed the problem silently in version 5.2.18 of its hardware virtualization software and did not give credit to the researcher for finding and reporting the vulnerability.

At the beginning of today's report, Zelnyuk clearly states the reasons that drove him to publicly announcing the full details for the current zero-day, before informing the developer of the issue. Oracle's past reaction to his reporting seems to have played a part in this.

1. Wait half a year until a vulnerability is patched is considered fine.
2. In the bug bounty field these are considered fine:
   1. Wait more than month until a submitted vulnerability is verified and a decision to buy or not to buy is made.
   2. Change the decision on the fly. Today you figured out the bug bounty program will buy bugs in a software, week later you come with bugs and exploits and receive "not interested".
   3. Have not a precise list of software a bug bounty is interested to buy bugs in. Handy for bug bounties, awkward for researchers.
   4. Have not precise lower and upper bounds of vulnerability prices. There are many things influencing a price but researchers need to know what is worth to work on and what is not.
3. Delusion of grandeur and marketing bullshit: naming vulnerabilities and creating websites for them; making a thousand conferences in a year; exaggerating importance of own job as a security researcher; considering yourself "a world saviour". Come down, Your Highness.

I'm exhausted of the first two, therefore my move is full disclosure. Infosec, please move forward.