Data Security

Russian exploit developer publicly disclosed VirtualBox zero-day vulnerability

An independent IT security researcher and exploit developer from Russia has publicly revealed a zero-day vulnerability in all versions of VirtualBox (VB) 5.2.20 and prior. VB is commonly used open source virtualization software that has been developed by Oracle.

According to the analysis of Sergey Zelenyuk, his exploit is hundred percent reliable and memory corruption issues are responsible for this zero-day vulnerability. It affects the Intel PRO / 1000 MT Desktop (82540EM) network card (E1000) if the network mode is set to Network Address Translation/NAT. The issue is prevailing in a shared code base of the virtualization software, which is available on literally all operating systems.

This vulnerability is not platform or OS specific primarily because it is present in a shared code base. Zelenyuk has also demonstrated the steps to follow for exploiting the vulnerability in a video. Through exploiting this flaw, an attacker can evade the virtual environment of a guest computer and gain easy and direct access to the Ring 3 privilege layer, which is used to run the coding of a majority of user programs with minimal privileges.

Zelenyuk discovered that the bug can be leveraged on those virtual machines that have been configured with Intel PRO/1000 MT Desktop (82540EM) network adapter only when it is in the NAT mode while the default setup lets the guest system to gain access to external networks. In his official blog post published on Tuesday, Zelenyuk explained the flaw quite clearly:

“The [Intel PRO/1000 MT Desktop (82540EM)] has a zero-day 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.”

He further stated that it is important to understand the way this flaw is exploited as it is the key to understanding how context descriptors are processed prior to data descriptors. In his video, Zelenyuk shows how necessary conditions are triggered to obtain a buffer overflow, which can be exploited to evade the confinements of the virtual operating system.

He used packet descriptors to produce an integer underflow condition, which are basically data segments that cause the network adapter to locate network packet data by searching the system memory. Next, Zelenyuk read data from the guest operating system into a stack buffer to create an overflow condition. This led to the overwriting of function pointers, which can be understood as a stack overflow condition.

He explained in his technical write-up that the exploit depends upon two overflow conditions and providers access to Ring 3 level permissions, therefore, to control the host operating system it is necessary to obtain privilege escalation. An attacker can do that by linking another vulnerability to attain increased privileges, which is a difficult process but certainly not impossible, writes Zelenyuk.

Moreover, the steps aren’t everyone’s piece of cake and would require advanced skills and technical know-how to be accomplished successfully. Zelenyuk tested his method on Ubuntu 16.04 and 18.04 on both 64-bit and 86-bit with default configuration. The video he has posted is proof of his success in getting the exploit running in the guest OS and execution of a shell on the host OS. The technical description is available on GitHub.

Zelenyuk also mentioned why did he disclose the vulnerability publically according to which: 

“I like VirtualBox and it has nothing to do with why I publish a 0day vulnerability. The reason is my disagreement with the contemporary state of infosec, especially of security research and bug bounty:

1: Wait half a year until a vulnerability is patched is considered fine.

2: In the bug bounty field these are considered fine:

i: Wait more than a month until a submitted vulnerability is verified and a decision to buy or not to buy is made.

ii: Change the decision on the fly. Today you figured out the bug bounty program will buy bugs in a software, a week later you come with bugs and exploits and receive “not interested”.

iii: Have not a precise list of software a bug bounty is interested to buy bugs in. Handy for bug bounties, awkward for researchers.

iv: 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 the 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.”

Since a patch isn’t yet available, you can protect yourself against the threat of cyber-attacks by changing your virtual machine’s network card to Paravirtualized Network or PCnet.

To Top

Pin It on Pinterest

Share This