
VirtualBox E1000 Guest-to-Host Escape - kpcyrd
https://github.com/MorteNoir1/virtualbox_e1000_0day
======
metafunctor
This [1] gives a little more background. The same security researcher found
another vulnerability in VirtualBox earlier this year, and didn't have a great
experience with Oracle:

“We reported this vulnerability to Oracle, the latest update from them is that
they are still looking into it, while in fact the latest version of Oracle
VirtualBox version 5.2.18 has silently introduced a patch without giving
credit or mentioning of the vulnerability report.”

[1]
[https://blogs.securiteam.com/index.php/archives/3736](https://blogs.securiteam.com/index.php/archives/3736)

~~~
SOLAR_FIELDS
Does Oracle have a track record of being The Worst about this or should I have
assumed as such given my preconceived notions of them being the classic
villain in the tech world?

~~~
skocznymroczny
"You need to think of Larry Ellison the way you think of a lawnmower. You
don't anthropomorphize your lawnmower, the lawnmower just mows the lawn, you
stick your hand in there and it'll chop it off, the end. You don't think 'oh,
the lawnmower hates me' \-- lawnmower doesn't give a shit about you, lawnmower
can't hate you. Don't anthropomorphize the lawnmower. Don't fall into that
trap about Oracle."

~~~
AlexanderDhoore
[https://www.youtube.com/watch?v=-zRN7XLCRhc](https://www.youtube.com/watch?v=-zRN7XLCRhc)

~~~
SOLAR_FIELDS
Entertaining talk.

The part that grandparent is quoting starts at about 38 minutes in.

------
cantrevealname
I think the author brings up a good point about so-called "responsible
disclosure" (a self-serving term by the vendors).

I'm paraphrasing his 3 reasons for disclosing immediately:

1\. It's unacceptable to wait half a year until a vulnerability is patched.

2\. Bug bounties are riddled with tricks to delay you, shenanigans as to
whether they'll pay you or not, and games to low ball the price.

3\. It's arrogant to wait months while meanwhile preparing for a big boastful
disclosure.

I'm thinking that we could add to this list as follows:

4\. The vulnerability might already be well-known and being used by black hats
and secret government agencies. Releasing the details immediately puts all of
us on an equal footing.

5\. Punish the vendors for having such awful security. Just the other day, HN
had an article[1] about Crucial SSDs that encrypt the drive with a key that
doesn't depend on the password; you can decrypt the drive without the password
just by patching the firmware. Is Crucial going to get punished for such an
outrageous lie about their encryption? The marketplace mechanisms that force
vendors to pay proper attention to security are trust in the brand,
independent security reviews (thank you security researchers!), government
regulation (no thank you), and _immediately_ naming and shaming them without
giving them time to cover it up or downplay it.

6\. Punish the users for not demanding higher security. Of course, we could
suffer as result, but it's not the security researcher who caused the bug and
it's not the security researcher who would be exploiting it. There needs to be
demand from users for higher security in their purchases.

7\. We get to see all the details if the vulnerability is disclosed
immediately. If the vulnerability is disclosed after "responsible disclosure",
plenty of times you don't get the raw details. I wouldn't be surprised if many
security researchers are signed to NDAs (or simply threatened by lawyers), so
we don't hear about the bugs _at all_. Having the full details published
immediately advances our knowledge in the security field more than a partial
disclosure months later (or a non-disclosure).

[1]
[https://news.ycombinator.com/item?id=18382975](https://news.ycombinator.com/item?id=18382975)

~~~
dexen
While you raise very good points overall, this one I have beef with:

>SSDs that encrypt the drive with a key that doesn't depend on the password

AFAIK, this is the standard practice in software harddrive/filesystem
encryption - LUKS, TrueCrypt, etc., for practical reasons, and with no
negative impact on security if properly implemented. AFAIK again, this is also
how Firefox handles encryption of stored website login/password credentials -
they are always encrypted using locally generated & held key; in case user
supplies her own password, this key is encrypted with that password, with no
change to the actual login/password store.

Contrast the following two scenarios:

\- derive encryption key from user-supplied password [potentially weak key]

\- encrypt the whole device / filesystem with the key [very long process,
prone to interruption]

\- user wishes to change the password

\- re-encrypt the whole device / filesystem with the new key [very long
process, prone to interruption]

vs.

\- generate a cryptographically secure random or pseudorandom key

\- store the password in device

\- encrypt device with the key from the first write onward

\- when user sets password, encrypt the stored key [no change to content of
device necessary]

\- from that point the user password is necessary to use the
decryption/encryption key

\- when the user changes password, re-encrypt the stored key only [no change
to content of device necessary]

The second scenario is also more amenable to implementing various multi-
password schemes, password-recovery techniques, and encryption secured with
both passwords and hardware tokens.

~~~
amdavidson
The difference is that the key was not encrypted with the password.

If the key were properly encrypted (as you describe) the password check could
not have been bypassed.

------
SethTro
I enjoyed reading the author's motivation for posting as a 0day vs Bug bounty.

[https://github.com/MorteNoir1/virtualbox_e1000_0day#why](https://github.com/MorteNoir1/virtualbox_e1000_0day#why)

~~~
TheSpiceIsLife
With regard to this, maybe there’s an opportunity for a market maker to step
in.

An “Uber for vulnerabilities”.

Having said that, I do tend to think “slap a market on it” can often lead to
perverse outcome.

~~~
cthor
These already exist. There are darknet firms that independently verify that an
exploit is real (staking their reputation that they won't take it and run once
shown), and then open it to the market.

The main trouble is that for it to fully work, you need to have the big corps
bidding against black hats in this market. I can't see that happening. It'd
have big corps dirtying their hands too openly.

The other trouble is that a lot of the damages (or value) of software bugs
aren't readily fungible to dollars. For example, to actually profit from the
Ashley Madison hack you'd need to blackmail a whole lot of people, which is
incredibly time consuming. So software firms would be able to underpay for
most exploits: The amount they'd be have to pay is at most what a black hat
can profit from the bug, which is necessarily less than the real damages
because the black hat has to cost for fungibility.

~~~
dev_dull
> _There are darknet firms that independently verify that an exploit is real
> (staking their reputation that they won 't take it and run once shown), and
> then open it to the market._

Is this really a thing? Who are these firms and what is their take?

~~~
icebraining
One example:
[http://www.zerodium.com/program.html](http://www.zerodium.com/program.html)

------
mrob
This is why local root exploits matter even if compromised userspace already
gives attackers control of everything in the VM. Don't update your kernel, and
maybe they'll get everything outside the VM too.

From the article: "Elevated privileges are required to load a driver in both
OSs. It's common and isn't considered an insurmountable obstacle. Look at
Pwn2Own contest where researcher use exploit chains: a browser opened a
malicious website in the guest OS is exploited, a browser sandbox escape is
made to gain full ring 3 access, an operating system vulnerability is
exploited to pave a way to ring 0 from where there are anything you need to
attack a hypervisor from the guest OS."

Defense in depth means caring about every link of the chain.

------
andrewstuart
The pricing of / evaluation of bug bounties seems to be a problem. Going
begging to the vendor of course results in reduced value.

Everything tends to be undervalued when there is only one buyer.

Also purchase processes tend to be slow when there is only one buyer.

It's almost as if there needs to be competition for the sale of the disclosure
... although that would have its own issues of course.

Another idea is a public timed/buy/disclosure board that offers security bugs
to the vendor at a certain price but if the vendor does not want to pay within
the time then it's released publicly. Effectively this is a concept in which
the researcher who found the bug decides on the price and the timeframe in
which it will be paid, rather than placing the decision in the hands of the
vendor. This too of course has issues. It's likely that things will go this
way though because security vulnerabilities are worth a great deal to
companies.

There's an opportunity right here for the startup who wishes to publicly list
vulnerabilities for sale to the vendor (only) at a given price within a given
time with escrow, else the researcher release to public. You'd have to find a
way to present it such that it is not extortion which might be hard, but in a
way that sort of what bug bounty programs are - reverse extortion. Bug
bounties are sort of saying "we'll pay you if you can exploit us but promise
not to", whereas extortion is saying "I know how to exploit you, pay me so I
won't". The big money goes to whichever startup finds how to present this in
an acceptable way.

~~~
fabianhjr
> Another idea is a public timed/buy/disclosure board that offers security
> bugs to the vendor at a certain price but if the vendor does not want to pay
> within the time then it's released publicly.

Problem with that is that it might be taken to be extortion / blackmailing /
racketeering. (Though, not a lawyer and this isn't legal advice)

------
userbinator
Great and very thorough writeup; the one biggest question I have left, is what
happens if you do this with the real hardware. Will it crash the hardware and
put it in a weird state, or will it do something natural and benign like
wrapround an internal counter modulo 16K?

------
barrystaes
Whats the CVE ? [1]

Next Critical Patch Updates by Oracle is scheduled at 15 January 2019. [2]

I see this bug exists at least in part in the open-source parts of VirtualBox.
[3] Could it be fixed there?

Could that (that part being opensource) also be reason for the researcher not
being granted the bug's bounty?

[1] [https://cve.mitre.org/cve/](https://cve.mitre.org/cve/)

[2]
[https://www.oracle.com/technetwork/topics/security/alerts-08...](https://www.oracle.com/technetwork/topics/security/alerts-086861.html)

[3]
[https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devic...](https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/Network/DevE1000.cpp#L4377)

------
niklasb
To give a bit of context to this discussion: Oracle does not and has never had
a bug bounty program. Honestly Oracle does not even play a big role in this.
From my experience with reporting VirtualBox bugs to them, they usually handle
them rather professionally.

The author must be referring to third-party, vendor-agnostic programs such as
the Zero Day Initiative (ZDI), SecuriTeam Secure Disclosure (SSD), or the
Accenture iDefense VCP (unless he was planning to sell to a non-disclosing
entity). Keep in mind that the main purpose of these programs is PR (in the
case of SSD) or a specific part of a security product (TippingPoint). I am not
surprised that the value of a vulnerability in these scenario varies heavily
over time. For example, if your purpose is to write a blog post and highlight
your security research, maybe it's not as interesting if you have written
another post about the same software recently.

The real question is, what is a business model by which a third party can make
money off of vulnerabilities despite reporting to the vendor. This is a tough
problem to solve. Maybe it's time to have the users of software contribute
financially in some way?

------
rplnt
The number 3. oh my. It's ridiculous what people do with the bugs their found
since Heartbleed. I don't remember anything like that before, but ever since
every security issue needs a logo and a catchphrase for some reason.

~~~
TazeTSchnitzel
It makes vulnerabilities easier to remember and talk about. Is that bad?

------
brobdingnagians
Given the prevalence of security flaws and the seriousness of the consequences
of a breach, I'm still surprised why people are so quick to dismiss high
security systems like OpenBSD. Just a couple of days ago someone was
incredulous that I would consider vmm from OpenBSD for virtual machines, but
I'd rather have a secure, open source virtual machine, than a bug infested
virtual machine from Oracle. But it is hard to argue with someone who has made
a billion dollars from bug infested software... I guess it is really a balance
between having cool new features people will buy and good-enough security for
your purpose (or good enough for your customers purposes anyways). Maybe I
should go work for Visa, they probably care about security.

------
umbs
I have a slightly off topic observation and couple of questions. Hoping to get
inputs from community. I'm half way through the write up and am amazed by the
amount of research, skill and grit that went in to finding this vulnerability.
Few questions I have:

1\. How do vulnerability researchers and RE engineers narrow down which code
base to test? VirtualBox code could be so huge.

2\. If their research leads to dead end, which I guess may happen most of the
time, how do they keep themselves going/motivated?

3\. Clearly, this work needs lots of time. How do they fund themselves to do
this?

4\. I believe a certain mindset is required to continue doing this work
because most of this is 'altruistic' in nature. The monetary reward is a
pittance. Would love to read some books on such topics.

------
user31421
This bug was already reported to Oracle:

[https://github.com/MorteNoir1/virtualbox_e1000_0day/issues/8](https://github.com/MorteNoir1/virtualbox_e1000_0day/issues/8)

------
wiz21c
FTA :

>>> a browser opened a malicious website in the guest OS is exploited, a
browser sandbox escape is made to gain full ring 3 access, an operating system
vulnerability is exploited to pave a way to ring 0 from where there are
anything you need to attack a hypervisor from the guest OS.

I cracked several games in the end of the 80's but that was nowhere as hard as
this seems to be. How do researchers find the time to go so deep in their
analysis ? Where do they learn ?

Anyway, the code analysis showed by the author is really good. That's so much
clever than old school "replace this check by NOP's" :-) Kudo's

~~~
saagarjha
> I cracked several games in the end of the 80's but that was nowhere as hard
> as this seems to be.

There are are many reasons for this. One is that with a game, you already have
full access to the program on your disc and can modify it at will, run it
infinitely many times, have full access to how it's loaded and run, and
analyze it separately. Plus "hacking a game" is not a security vulnerability,
and the only person who loses if you add an RCE to your game is you, and
possibly the publisher if you crack it.

------
johanhammar
Seems like the issue has been fixed in VirtualBox 5.2.22

[https://github.com/MorteNoir1/virtualbox_e1000_0day/issues/1...](https://github.com/MorteNoir1/virtualbox_e1000_0day/issues/12)
[https://www.virtualbox.org/wiki/Changelog#22](https://www.virtualbox.org/wiki/Changelog#22)

------
abmateen
Very interesting read, I browsed the author's website and it says he is a
independent security researcher and self employed, a real question, I am
interesting in knowing he survives just reporting bugs, when there is no
surety a bug could be found every month for a living....

------
dabockster
As soon as I read the phrase "ASLR bypass", I knew this would be devastating.

------
alsadi
I guess SELinux/SVirt would mitigate this

------
voltagex_
Is qemu affected?

~~~
exikyut
The exploit half impacts the E1000 driver, but the other half impacts
VirtualBox's implementation of the virtualized system; so no.

Specifically, the write primitive exploits the way the E1000's EEPROM is
emulated, and you can see the read primitive exploits VirtualBox's ACPI
implementation.

------
jiveturkey
huh. is the author a known “security researcher”? i agree more or less with
his 3 points.

~~~
ehsankia
The author here just blindly assumes a lot of things about VirtualBox's bug
bounty program. Many, like Google, put a very strict limit, and they will
release the details when that time is over. I think it's more respectful to at
least give them a chance, rather than throwing a hot shit on their lap and
making hundreds of people's life a living hell for a week.

The engineers in charge quickly patching this up aren't the ones who came up
with the bounty program. Making them pay for it seems like a pretty shitty
move.

~~~
bdhess
> rather than throwing a hot shit on their lap

Well really, Oracle threw the hot shit in customers’ laps. The author just had
the gall to point it out.

> making hundreds of people's life a living hell for a week

> Making them pay for it seems like a pretty shitty move.

It sounds like you assume Oracle is going to abuse its staff in the process of
getting this fixed. I don’t know why you assume that, nor why the author ought
to be blamed if Oracle does.

~~~
ehsankia
> Oracle threw the hot shit

Right, Oracle as an organization did, not necessarily the engineers who will
be tasked with fixing this.

> Oracle is going to abuse its staff

Not necessarily abuse, but obviously, having 30 days to fix something is a
much more saner experience than when every minute counts.

------
paulie_a
Not to discount the work done here. Big high five. But I am surprised hundreds
more of these bugs haven't found every week. It's Oracle. Their mission
statement might as well be "we make security vulnerabilities and charge you a
shitload"

I would never trust any Oracle product in any form in production environment.

~~~
freedomben
I hate Oracle and consider them among the most evil of companies out there.
However, I don't think that's a very fair characterization of their mission
statement.

~~~
cyphar
I think [1] shows that it is far from being an unfair synopsis of their
mission statement.

[1]:
[https://news.ycombinator.com/item?id=10039202](https://news.ycombinator.com/item?id=10039202)

------
ChickeNES
Oh, this might explain how I managed to cause the host OS to crash while
running my homebrew OS when I was in college...

~~~
exikyut
Homebrew OS? Interesting. What did it do? Can I see it anywhere?

What VM were you using?

Host OS crashes like what you describe are no-trust-me-it's-really-not-the-
compiler unlikely.

I did have X crash on me once while figuring out the X11 protocol
specification, but that's because X is widely known to be less than perfectly
stable :D and also because the actual graphics driver I was using was a little
flaky.

~~~
ChickeNES
I took an OS class and wanted to learn more afterwards so I hacked together a
small kernel mostly using info from the osdev wiki. I got decently far
(managed to have a shell running, had VIM running), but ran out of steam years
ago (that and the code needing a massive amount of cleanup and auditing).

So I misremembered (it's been 6+ years ago) but it was the AMD PCNET driver I
wrote that triggered the crash, not E1000. Excuse the code quality, but the
driver I wrote is located here:
[https://github.com/blanham/ChickenOS/blob/master/src/device/...](https://github.com/blanham/ChickenOS/blob/master/src/device/net/pcnet.c)
(Note the comment about it not working in Virtualbox) Attempting to boot my
kernel with that driver activated would cause a hard freeze of the host OS,
requiring a hard reset of the host machine. I replicated this multiple times,
in Virtualbox for both OSX and Windows.

Thanks for actually replying instead of downvoting, I guess I shouldn't make
off-the-cuff comments and then forget to follow-up until the next day.

~~~
exikyut
Interesting. I've been eyeing OS development for a while myself. I have a few
high-level ideas about kernel design, and a few years's worth of musings about
good UX. I badly need to get on with spending a few years getting my feet wet
with actual implementation details and such so I'm not just a pile of
unorientated hot air though, haha. Armchair pontificating doesn't count for
much. But anyway.

Huh, a shell and Vim. (Alongside multiple architecture support and two
filesystems.) That's reasonably developed-out. Not bad!

Can totally understand the problem of running out of steam. (I think that
might be why I've been so hesitant about diving in myself - want to pace
things so they stay interesting for long enough, and don't want to make too
many discouraging mistakes. A couple kernel architecture arguments doesn't
produce a good filesystem, adequately future-proof UI model, good vertical
"little detail" semantics, etc etc.

A hard crash on multiple platforms? That's almost definitely a bug. Heh, I
think all the downvoters might've made a bunch of incorrect presumptions there
:)

It might be mildly interesting to see if you can still trigger the crash with
the latest version of VirtualBox. (I'd have a go but of course I have no repro
details, or info on how to actually build everything for that matter.)

Precedent has just been set on 0daying VB networking hardware, for what that's
worth :P but there's also Project Zero (which will accept security
vulnerabilities in any software, and imposes a 90-day deadline) if VB's own
bug bounty thing proves unappealing. This is of course getting a bit ahead of
testing/re-verification. I mention it because I'm now very curious to know if
the bug is still there, but of course HN comments are not the right place for
a [Y] :)

It's impossible to say if recreating the test environment (host OS version(s),
host VirtualBox version) would prove fruitful if the latest VB versions seem
(...seem...) immune. Vulnerability research seems to be consist of a lot of
"hmm, that seems like it _might_ run a tiny bit slower on months with a Q in
them if the computer is leaning 30° to the left at 2:14PM in the afternoon"
and then staring at Hex-Rays for 3 months to ultimately prove that your crazy
theory is in fact valid (literal example [https://ramtin-
amin.fr/#nvmedma;](https://ramtin-amin.fr/#nvmedma;) very similar example
[https://bugs.chromium.org/p/chromium/issues/detail?id=648971](https://bugs.chromium.org/p/chromium/issues/detail?id=648971)
\- "one byte overflow"!).

In any case, I wouldn't mind getting some more details and seeing the _CLUNK_
in action. It's interesting at face value.

NB. About that nvmedma link - it took me about 4-5 rereads of that article and
its prequel ([https://ramtin-amin.fr/#nvmepcie](https://ramtin-
amin.fr/#nvmepcie)) before the bigger picture started to click.

(I also need to check my comments somewhat frequently - and then remember to
also actually follow-up after seeing I have replies! Woops. Thanks for the
reply!)

