Skip to content
Naked Security Naked Security

Ranting researcher publishes VM-busting zero-day without warning

A security researcher has published a zero-day flaw in a commonly-used virtual machine management system without notifying the vendor, justifying it with a scathing critique of the infosecurity industry.

A security researcher has published a zero-day flaw in a commonly-used virtual machine management system without notifying the vendor, justifying it with a scathing critique of the infosecurity industry.
St Petersburg-based Sergey Zelenyuk dropped the bug, which affects Oracle’s VirtualBox software, on GitHub this week
We’re linking to the bug here because Zelenyuk provides a workaround, and attackers will be at an advantage if they see it and you don’t. The vulnerability lies in the way that default VirtualBox virtual machines treat network communications. The virtual network card lets an attacker with administrative privileges escape to the host operating system.
To exploit the flaw, an attacker first turns off the E1000 virtual network card in the guest OS. They then load their own Linux kernel module (LKM), which is a piece of code that extends Linux’s functionality without having to reboot the system. This LKM, which contains the exploit code, starts its own E1000 virtual network card. The LKM then exploits a buffer overflow vulnerability in the virtual network card, which enables it to gain access to the host system. After that, the attacker can unload the LKM and restart the original E1000 virtual network card so that they can use the network again.
There are some caveats to this attack. The first is that the attacker must have escalated (administrative) privileges on the guest OS. As Zelenyuk points out, though, this is workable, as other exploits can escalate user privileges.
The other caveat is that the attack only gives the hacker access to what’s usually known as “userland” on the host computer, rathen that access to the host operating system itself.
Nevertheless, the ability to escape from a virtual machine (VM) to the host computer that’s in charge of the VM has serious consequences – especially if the host is running VMs on behalf of a bunch of different users.


The VirtualBox bug is notable in its own right, but equally interesting is Zelenyuk’s approach. Although he didn’t publish an actual proof of concept executable, he provided extensive details of the exploit without telling Oracle first – a blurt-it-out-publicly approach known as full disclosure.
These days, full disclosure is widely frowned upon in cybersecurity circles, with many researchers following a gentler approach known as responsible disclosure, telling the vendor first and giving them time to fix it.
The researcher said:

I like VirtualBox and it has nothing to do with why I published 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.

In point two, he claims that bug bounty programs take too long to verify vulnerabilities, change their minds, and don’t provide enough information about the types of vulnerabilities they are interested in or how much they are willing to pay.
Finally, he goes on a hyperbolic rant about the industry in general:

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.

We asked Oracle, which wouldn’t comment, but instead directed us to its disclosure policies, which say that for a researcher to be credited, “they must follow responsible disclosure practices”. One of these is:

They do not publish the vulnerability prior to Oracle releasing a fix for it.

10 Comments

Sadly, I tend to agree with the publisher of the Zero Day. Security is such a joke until people get punished for a breach or failure to follow basic security concepts. By the time the punishment is doled out, it is after the fact, when most of this can be prevented in the 1st place. Security will only get worse as code gets more complex and for a whole host of other reasons.

Reply

I like how Google and M$ seems to be at each others throats with their respective security research teams. Good ol’ Goog gives M$ something like 90 days after they disclose before they release it. Now this was some time ago, and they could have hammered out their disagreements since. But NS did share a few back and forths a couple of years back.
Responsible disclosure, sure, but the should be held to a timeline, i.e. 90 days, to effect the code change or their product get owned, and by unfortunate extension, the poor sods using it.
If coding is a craft, then the craftsmen and women, should take more responsibility for what they create. Large for profit companies need to look less at their bottom line and deadlines; they need to concentrate on more than meeting just the bare minimum. As Jim said, code gets more complex, so more time needs to be dedicated to cleaning up the old, so your applications don’t end up bloated. Or just move to an Agile dev method.

Reply

This guy was wrong to disclose it the way he did, unless Oracle had previously short-circuited the disclosure process with him. The industry in general should never be a target of any rant that include irresponsible (full) disclosure.
However, I also have a bone to pick with Oracle for their definition of responsible disclosure: researchers shouldn’t have to wait for Oracle to fix a problem. There needs to be a time limit, along with methods of communicating between the researcher and the company to extend that limit. Oracle’s definition leaves it open to non-disclosure indefinitely, and that’s not right, either. (But, not as bad as the irresponsible disclosure.)

Reply

I disagree on your last part. I think not disclosing it indefinitely and in turn not having any pressure to fix it is much worse than it just being disclosed without prior notice. Even without a researcher disclosing a vulnerability the chances are high that some attackers already found it or will find it regardless. So I’d rather have the vendor pressured into a fix and the vulnerability being disclosed than to everything being kept quiet but also no pressure for a fix. Ideally it’s a policy along the lines of google, with notifying the vendor but also giving them a timeline. But if that is not an option I’d rather know whats wrong and know they are working on a fix.

Reply

It seems to me like this researcher may have been shafted by Oracle out of a previous bug bounty.

Reply

Except for his note that “I like VirtualBox and it has nothing to do with why I published a 0day vulnerability.”

Reply

True…except those *could* be mutually exclusive.
Duck, I gotta say I’m seriously disappointed in you.
To learn in such a brutal, sudden manner that you’re not a world savio(u)r after all…
*my* world is now shattered.
:,(

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!