9 ms·

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/Morte

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.
    - matt4077 8y ago
      So... It's okay to harm third parties, i. e. VirtualBox users, not just as an unfortunate but unavoidable side effect, but as your means to punish the vendor for their (neglient? wilful? morally depraved?) failure to follow the idealised processes you envision, and for not honouring your genius with whatever your ego believes it is owed?
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]

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.
  - matt4077 8y ago
    So... It's okay to harm third parties, i. e. VirtualBox users, not just as an unfortunate but unavoidable side effect, but as your means to punish the vendor for their (neglient? wilful? morally depraved?) failure to follow the idealised processes you envision, and for not honouring your genius with whatever your ego believes it is owed?

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]