Russian researcher publishes detailed write-up for VirtualBox zero-day on GitHub after Oracle took 15 months to fix a previous similar issue.
A Russian security researcher has published details about a zero-day vulnerability affecting VirtualBox, an Oracle software application for running virtual machines.
According to a text file uploaded on GitHub, Saint Petersburg-based researcher Sergey Zelenyuk has found a chain of bugs that can allow malicious code to escape the VirtualBox virtual machine (the guest OS) and execute on the underlying (host) operating system.
Once out of the VirtualBox VM, the malicious code runs in the OS' limited userspace (kernel ring 3), but Zelenyuk said that attackers can use many of the already known privilege escalation bugs to gain kernel-level access (ring 0).
"The exploit is 100% reliable," Zelenyuk said. "It means it either works always or never because of mismatched binaries or other, more subtle reasons I didn't account."
The Russian researcher says the zero-day affects all current VirtualBox releases, works regardless of the host or guest operating system the user is running, and is reliable against the default configuration of newly created VMs.
Besides a detailed write-up of the entire exploit chain, Zelenyuk has also published video proof, showing the zero-day in action against an Ubuntu VM running inside VirtualBox on an Ubuntu host OS.
The zero-day is not considered a threat to cloud hosting environments, which also heavily depend on virtual machines. Most cloud computing services use a Type-1 (native) hypervisor -- which runs directly on the server hardware-- to manage virtual machines. VirtualBox is a Type-2 hypervisor, as it runs a VM (guest OS) inside an already-running OS (host OS).
The vulnerability has security researchers panicking because VirtualBox is one of the most popular VM applications used for day-to-day malware analysis and reverse engineering.
Many have expressed concerns that malware authors may embed the zero-day's exploit chain inside malware strains that will then be able to escape VirtualBox VMs and infect the researcher's main operating systems with malware, as payback.
Today's zero-day disclosure is also the second virtual machine escape that Zelenyuk has discovered affecting VirtualBox. He found and reported a similar issue in mid-2017, which Oracle took over 15 months to fix.
This lengthy and drawn-out patching process appears to have angered Zelenyuk, who instead of reporting this bug to Oracle, has decided to publish details online without notifying the vendor. Knowing his decision would be criticized, Zelenyuk offered the following reasons for taking this somewhat controversial step:
I like VirtualBox and it has nothing to do with why I publish a 0day vulnerability. The reason is my disagreement with 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 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, 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 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.