12 ms·

VirtualBox E1000 Guest-to-Host Escape

577 points by kpcyrd 8y ago

voltagex_ 8y ago
Is qemu affected?
- exikyut 8y ago
  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.
SethTro 8y ago
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
- metildaa 8y ago
  The author has a number of great points, with an overarching theme that how we handle security bugs is ridiculous.
  - artursapek 8y ago
    Especially the websites/branding of bugs, like Heartbleed, SHAttered, etc. It seems like researchers do this to propel their own fame, for probably financial motives. I imagine it's pretty lucrative to have been the "co-founder" of Heartbleed just like it is lucrative to be the co-founder of a well-known startup.
    - metildaa 8y ago
      There are better outcomes from doing these kinds of bug brandings, it creates awareness of sometimes serious vulnerabilities and gives us something more friendly to reference a bug by than its CVE #. Who remembers the CVE # for Blueborne or Heartbleed?
    - jayflux 8y ago
      There is truth in that but I do think it makes them easier to refer to when you talk about them 5 years later, I still remember Heartbleed. If someone said to me “Hey, remember when CVE-2014-0160 happened?” I would be like what was that? So yeah, the awareness side of it helps
  - xupybd 8y ago
    You don't think there is a place for giving vendors time to fix the exploit before handing it over to everyone who can use it maliciously?
    - pryce 8y ago
      Even the the author publishing this 0day clearly believes there is a place for that; their protest is calling attention to that this time-to-fix period is, they believe, in practice abused to be a great deal longer than it should be. Putting aside the ethics of publishing this 0day, I feel like it's important to critique the more nuanced point the author is making, rather than critique a caricature of it.
    - nur0n 8y ago
      The security of the product is the responsibility of the vendors. If they want to control how exploits are handled, then they should compensate security researchers for that service, just like anything else. The poster of the exploit outlined some reasonable steps to that end. I'm no security expert, but the feeling I get from other discussions is that big players have acted dishonestly with regards to proper compensation of bug bounties. It seems that sad state of affairs is being protested.
      - metildaa 8y ago
        Most companies and organizations react terribly to being made aware of security issues, sometimes landing the messenger in prison. Prevailing practices are to sweep vulnerabilities under the rug, or quietly acknowledge them and hope no one notices.
    - metildaa 8y ago
      Not at the cost of leaving end users vulnerable and in the dark, vendors can deal with the consequences of their choices. Hard lessons are needed, having attempted to disclose serious vulnerabilities in T-Mobile USA's APIs by reaching out repeatedly, most vendors will not patch in an urgent manner, and some (like T-Mobile) are content to leak customer info indefinitely. It is a culture problem, and it will take (financial and reputational) pain to alter the existing corporate cultures.
- TheSpiceIsLife 8y ago
  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.
  - niklasb 8y ago
    I think the author is referring to third parties which buy and disclose vulnerabilities. Very hard to monetize. There is already a flourishing market for undisclosed vulnerabilities, for obvious reasons.
  - auslander 8y ago
    It is called darknet :)
    - TheSpiceIsLife 8y ago
      Sorry, I should have been clearer. I meant a non-darknet market. Like somehow being able to have a third party negotiate payout rates for bug bounties. I have no idea what the might look like.
      - cthor 8y ago
        Probably would look like a union (a dirty word in software), where their collective bargaining allows them to have leverage on software firms and have policies to punish non-payment in an ethical way. Sequence looks something like: Security researcher submits exploit to the union. Union verifies it and decides it's worth $x. They inform software firm of the exploit and a deadline for payment. If payment is received before deadline, they get full, private disclosure. If not, then exploit is made public. Union takes a cut. Security researchers don't really need a market maker. (It's not a real market: Actually converting exploits into money is typically antisocial and illegal.) They need someone to negotiate for them.
        jstanley 8y ago
        That's starting to sound quite close to blackmail. "I have remote code execution in your product, pay me XXX or I'll tell everyone". I don't actually know if it is blackmail, but if it is, hiding behind a union isn't enough to make it not-blackmail.
- viraptor 8y ago
  I find that part really weird. These are two extremes - you can easily notify the vendor and give them a month (or whatever period you think is reasonable) to fix the issue if you're not interested in the bounty. Google was pretty successful with enforcing 3 months. VirtualBox may not be a production service where it really matters, but publishing a 0day makes for some stressful days for many ops.
  - craftyguy 8y ago
    After reading the description of the exploit, it's not clear to me who is at fault. It almost seems like there are several bugs in the Intel E1000 driver, and not VirtualBox. But then again, the hypervisor should probably never allow a guest kernel to escape the VM. If the issue actually lies with VirtualBox, VirtualBox is owned/maintained by Oracle, and based on other interactions I've seen with Oracle I wouldn't be surprised if others have submitted exploits to them before and they were ignored.
    - niklasb 8y ago
      The bug is in the VirtualBox code that emulates an Intel E1000 device. There is no driver code involved.
      - craftyguy 8y ago
        Thanks. > There is no driver code involved. Yea I see that step #1 in the 'exploit algo' is to remove the e1000, I missed that earlier: > An attacker unloads e1000.ko loaded by default in Linux guests and loads the exploit's LKM.
- deleted 8y ago
  [deleted]
userbinator 8y ago
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?
paulie_a 8y ago
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 8y ago
  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.
  - Nerdfest 8y ago
    True, I think it's actually Adobe's.
  - cyphar 8y ago
    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
  - paulie_a 8y ago
    It's called exaggerated sarcasm. But it is absolutely fair of the products they build. They are complete garbage. It's like Adobe and Oracle have a side bet on who can introduce the most vulnerabilities. That is how terrible of a track record they have. I will be extreme here and say all of their products, especially Java, flash, and acrobat should outright be banned from a corporate network. It should be considered a liability and insurance companies should actually build it into their models.
- monocasa 8y ago
  To be fair, this is Sun (or probably Innotek) code almost certainly. Sun I generally trusted in production.
- fulafel 8y ago
jiveturkey 8y ago
huh. is the author a known “security researcher”? i agree more or less with his 3 points.
- ehsankia 8y ago
  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.
  - exikyut 8y ago
    OK, so a bunch of engineers have been told to drop everything to patch this. Maybe work weekends, (hopefully not) provide hourly updates on their work, etc. I don't see fixing this as entirely tricky; the patch looks to be a few lines of code. Then it's over to testing for a short run, and the release team will be running around informing vendors in order of importance and then updating https://www.virtualbox.org/wiki/Changelog https://www.virtualbox.org/wiki/Changelog, which incidentally hasn't changed yet (it will be interesting to see when this happens / how long it takes). So that's the on-the-ground mess that's been made. It's annoying, but not the end of the world, so concentrating only on the lowest level is arguably a distraction from the bigger picture - which is impacted by all such events as this.
  - bdhess 8y ago
    > 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.
andrewstuart 8y ago
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 8y ago
  > 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)
- deleted 8y ago
  [deleted]
ChickeNES 8y ago
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 8y ago
  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 8y ago
    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/net/pcnet.c https://github.com/blanham/ChickenOS/blob/master/src/device/... (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 8y ago
      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!)
mrob 8y ago
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.
cantrevealname 8y ago
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
- wiz21c 8y ago
  yep, all of that is equivalent to "security by obscurity". Hiding vulnerabilities longer is of no use, it just helps companies to be ready to answer customers, not to fix things in a better way.
  - 8y ago
deleted 8y ago
[deleted]
metafunctor 8y ago
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 8y ago
  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?
  - bayindirh 8y ago
    Relevant discussion in another Oracle related post[0]. [0]: https://news.ycombinator.com/item?id=18389481 https://news.ycombinator.com/item?id=18389481
    - SOLAR_FIELDS 8y ago
      I do like that post because it summarizes how I feel about Oracle rather succinctly. For your typical FAANG company, the money is the means to the end. But for Oracle, the money is the end to the means.
  - Uberphallus 8y ago
    Oracle has a track record of being The Worst about anything.
    - haloux 8y ago
      This sounds interesting, would you mind going into detail about this? Maybe a quick list?
wiz21c 8y ago
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 8y ago
  > 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.
- tinus_hn 8y ago
  Of course they started with exploiting the emulated device using a VM where they have full control. The rest is just to show a scenario where this is actually a problem.
dabockster 8y ago
As soon as I read the phrase "ASLR bypass", I knew this would be devastating.
barrystaes 8y ago
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-086861.html https://www.oracle.com/technetwork/topics/security/alerts-08... [3] https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/Network/DevE1000.cpp#L4377 https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devic...
rplnt 8y ago
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.
- j0hnml 8y ago
  Yeah, this is all too true, and unfortunately it gives the security industry a bad rap
- TazeTSchnitzel 8y ago
  It makes vulnerabilities easier to remember and talk about. Is that bad?
brobdingnagians 8y ago
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.
abmateen 8y ago
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....
niklasb 8y ago
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?
alsadi 8y ago
I guess SELinux/SVirt would mitigate this
umbs 8y ago
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 8y ago
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
johanhammar 8y ago
Seems like the issue has been fixed in VirtualBox 5.2.22 https://github.com/MorteNoir1/virtualbox_e1000_0day/issues/12 https://github.com/MorteNoir1/virtualbox_e1000_0day/issues/1... https://www.virtualbox.org/wiki/Changelog#22 https://www.virtualbox.org/wiki/Changelog#22

577 points by kpcyrd 8y ago

voltagex_ 8y ago

Is qemu affected?

exikyut 8y ago
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.

SethTro 8y ago

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

metildaa 8y ago
The author has a number of great points, with an overarching theme that how we handle security bugs is ridiculous.
- artursapek 8y ago
  Especially the websites/branding of bugs, like Heartbleed, SHAttered, etc. It seems like researchers do this to propel their own fame, for probably financial motives. I imagine it's pretty lucrative to have been the "co-founder" of Heartbleed just like it is lucrative to be the co-founder of a well-known startup.
  - metildaa 8y ago
    There are better outcomes from doing these kinds of bug brandings, it creates awareness of sometimes serious vulnerabilities and gives us something more friendly to reference a bug by than its CVE #. Who remembers the CVE # for Blueborne or Heartbleed?
  - jayflux 8y ago
    There is truth in that but I do think it makes them easier to refer to when you talk about them 5 years later, I still remember Heartbleed. If someone said to me “Hey, remember when CVE-2014-0160 happened?” I would be like what was that? So yeah, the awareness side of it helps
- xupybd 8y ago
  You don't think there is a place for giving vendors time to fix the exploit before handing it over to everyone who can use it maliciously?
  - pryce 8y ago
    Even the the author publishing this 0day clearly believes there is a place for that; their protest is calling attention to that this time-to-fix period is, they believe, in practice abused to be a great deal longer than it should be. Putting aside the ethics of publishing this 0day, I feel like it's important to critique the more nuanced point the author is making, rather than critique a caricature of it.
  - nur0n 8y ago
    The security of the product is the responsibility of the vendors. If they want to control how exploits are handled, then they should compensate security researchers for that service, just like anything else. The poster of the exploit outlined some reasonable steps to that end. I'm no security expert, but the feeling I get from other discussions is that big players have acted dishonestly with regards to proper compensation of bug bounties. It seems that sad state of affairs is being protested.
    - metildaa 8y ago
      Most companies and organizations react terribly to being made aware of security issues, sometimes landing the messenger in prison. Prevailing practices are to sweep vulnerabilities under the rug, or quietly acknowledge them and hope no one notices.
  - metildaa 8y ago
    Not at the cost of leaving end users vulnerable and in the dark, vendors can deal with the consequences of their choices. Hard lessons are needed, having attempted to disclose serious vulnerabilities in T-Mobile USA's APIs by reaching out repeatedly, most vendors will not patch in an urgent manner, and some (like T-Mobile) are content to leak customer info indefinitely. It is a culture problem, and it will take (financial and reputational) pain to alter the existing corporate cultures.
TheSpiceIsLife 8y ago
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.
- niklasb 8y ago
  I think the author is referring to third parties which buy and disclose vulnerabilities. Very hard to monetize. There is already a flourishing market for undisclosed vulnerabilities, for obvious reasons.
- auslander 8y ago
  It is called darknet :)
  - TheSpiceIsLife 8y ago
    Sorry, I should have been clearer. I meant a non-darknet market. Like somehow being able to have a third party negotiate payout rates for bug bounties. I have no idea what the might look like.
    - cthor 8y ago
      Probably would look like a union (a dirty word in software), where their collective bargaining allows them to have leverage on software firms and have policies to punish non-payment in an ethical way. Sequence looks something like: Security researcher submits exploit to the union. Union verifies it and decides it's worth $x. They inform software firm of the exploit and a deadline for payment. If payment is received before deadline, they get full, private disclosure. If not, then exploit is made public. Union takes a cut. Security researchers don't really need a market maker. (It's not a real market: Actually converting exploits into money is typically antisocial and illegal.) They need someone to negotiate for them.
      - jstanley 8y ago
        That's starting to sound quite close to blackmail. "I have remote code execution in your product, pay me XXX or I'll tell everyone". I don't actually know if it is blackmail, but if it is, hiding behind a union isn't enough to make it not-blackmail.
viraptor 8y ago
I find that part really weird. These are two extremes - you can easily notify the vendor and give them a month (or whatever period you think is reasonable) to fix the issue if you're not interested in the bounty. Google was pretty successful with enforcing 3 months. VirtualBox may not be a production service where it really matters, but publishing a 0day makes for some stressful days for many ops.
- craftyguy 8y ago
  After reading the description of the exploit, it's not clear to me who is at fault. It almost seems like there are several bugs in the Intel E1000 driver, and not VirtualBox. But then again, the hypervisor should probably never allow a guest kernel to escape the VM. If the issue actually lies with VirtualBox, VirtualBox is owned/maintained by Oracle, and based on other interactions I've seen with Oracle I wouldn't be surprised if others have submitted exploits to them before and they were ignored.
  - niklasb 8y ago
    The bug is in the VirtualBox code that emulates an Intel E1000 device. There is no driver code involved.
    - craftyguy 8y ago
      Thanks. > There is no driver code involved. Yea I see that step #1 in the 'exploit algo' is to remove the e1000, I missed that earlier: > An attacker unloads e1000.ko loaded by default in Linux guests and loads the exploit's LKM.
deleted 8y ago
[deleted]

userbinator 8y ago

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?

paulie_a 8y ago

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 8y ago
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.
- Nerdfest 8y ago
  True, I think it's actually Adobe's.
- cyphar 8y ago
  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
- paulie_a 8y ago
  It's called exaggerated sarcasm. But it is absolutely fair of the products they build. They are complete garbage. It's like Adobe and Oracle have a side bet on who can introduce the most vulnerabilities. That is how terrible of a track record they have. I will be extreme here and say all of their products, especially Java, flash, and acrobat should outright be banned from a corporate network. It should be considered a liability and insurance companies should actually build it into their models.
monocasa 8y ago
To be fair, this is Sun (or probably Innotek) code almost certainly. Sun I generally trusted in production.
fulafel 8y ago

jiveturkey 8y ago

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

ehsankia 8y ago
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.
- exikyut 8y ago
  OK, so a bunch of engineers have been told to drop everything to patch this. Maybe work weekends, (hopefully not) provide hourly updates on their work, etc. I don't see fixing this as entirely tricky; the patch looks to be a few lines of code. Then it's over to testing for a short run, and the release team will be running around informing vendors in order of importance and then updating https://www.virtualbox.org/wiki/Changelog https://www.virtualbox.org/wiki/Changelog, which incidentally hasn't changed yet (it will be interesting to see when this happens / how long it takes). So that's the on-the-ground mess that's been made. It's annoying, but not the end of the world, so concentrating only on the lowest level is arguably a distraction from the bigger picture - which is impacted by all such events as this.
- bdhess 8y ago
  > 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.

andrewstuart 8y ago

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 8y ago
> 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)
deleted 8y ago
[deleted]

ChickeNES 8y ago

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 8y ago
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 8y ago
  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/net/pcnet.c https://github.com/blanham/ChickenOS/blob/master/src/device/... (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 8y ago
    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!)

mrob 8y ago

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.

cantrevealname 8y ago

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

wiz21c 8y ago
yep, all of that is equivalent to "security by obscurity". Hiding vulnerabilities longer is of no use, it just helps companies to be ready to answer customers, not to fix things in a better way.
- 8y ago

deleted 8y ago

[deleted]

metafunctor 8y ago

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 8y ago
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?
- bayindirh 8y ago
  Relevant discussion in another Oracle related post[0]. [0]: https://news.ycombinator.com/item?id=18389481 https://news.ycombinator.com/item?id=18389481
  - SOLAR_FIELDS 8y ago
    I do like that post because it summarizes how I feel about Oracle rather succinctly. For your typical FAANG company, the money is the means to the end. But for Oracle, the money is the end to the means.
- Uberphallus 8y ago
  Oracle has a track record of being The Worst about anything.
  - haloux 8y ago
    This sounds interesting, would you mind going into detail about this? Maybe a quick list?

wiz21c 8y ago

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 8y ago
> 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.
tinus_hn 8y ago
Of course they started with exploiting the emulated device using a VM where they have full control. The rest is just to show a scenario where this is actually a problem.

dabockster 8y ago

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

barrystaes 8y ago

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-086861.html https://www.oracle.com/technetwork/topics/security/alerts-08... [3] https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/Network/DevE1000.cpp#L4377 https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devic...

rplnt 8y ago

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.

j0hnml 8y ago
Yeah, this is all too true, and unfortunately it gives the security industry a bad rap
TazeTSchnitzel 8y ago
It makes vulnerabilities easier to remember and talk about. Is that bad?

brobdingnagians 8y ago

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.

abmateen 8y ago

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....

niklasb 8y ago

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?

alsadi 8y ago

I guess SELinux/SVirt would mitigate this

umbs 8y ago

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 8y ago

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

johanhammar 8y ago

Seems like the issue has been fixed in VirtualBox 5.2.22 https://github.com/MorteNoir1/virtualbox_e1000_0day/issues/12 https://github.com/MorteNoir1/virtualbox_e1000_0day/issues/1... https://www.virtualbox.org/wiki/Changelog#22 https://www.virtualbox.org/wiki/Changelog#22