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.

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.

The bug is in the VirtualBox code that emulates an Intel E1000 device. There is no driver code involved.

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.

The author has a number of great points, with an overarching theme that how we handle security bugs is ridiculous.

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?

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.

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.

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.

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.

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?

The harm is already there, you're just shooting the messenger.

Considering https://blogs.securiteam.com/index.php/archives/3736 I'm not too surprised they just went "fuck you Oracle" this time.

IMO the vendor should employ security researchers so their customers don't have to rely on outside volunteers to expose the bugs in the software they bought. The responsible disclosure talk often is just blame shifting.

I think the market should demand and suppliers offer a better baseline of security in prevention and turnarounds for fixes. The market mostly doesn't pay for better security. Suppliers mostly don't care either. So, most software is intentionally vulnerable with users/buyers accepting and rewarding that. That means 0-days are coming no matter what, esp if development processes don't improve. Publishing a 0-day seems at least no more unethical than the demand and supply side intentionally putting them there in the first place. I've actually started thinking security people should cash in on the practice in a way that funds secure alternatives like I said on Lobste.rs version of this article:

"There’s no regulations or liability. The market largely doesn’t care. They outsource security work, even stuff as easy as 15 min of AFL, to unpaid labor that has to beg for payouts that are often below market rate for paid, security professional. If they refuse to do secure development, I say just publish the vulnerabilities or sell them to Zerodium. Also, keep recommending secure alternatives to common, vulnerable software.

I did have another idea when looking at the fact that high-security software is always too expensive for most to buy or sold/free at a loss. Companies like Zerodium pay a fortune for vulnerabilities in software. It’s always the same software, too, whose developers keep adding preventable vulnerabilities. Usually a company making piles of money off it, too. So, sell vulnerabilities in those apps which already have red flags for security-conscious users, make a bit of money for yourself out of that, and spend the rest (eg majority) on developing secure alternatives. For example, selling vulnerabilities in Nginx to carefully extend and tool-check lwan, in consumer routers to fund an OpenBSD-based router, and/or iOS to fund HardenedAndroid (or new mobile OS). Stuff like that.

Hardly anyone will pay for real security. They’ll pay for vulnerabilities, though. Sad it comes to ideas like that but it’s one of the only ones that easily generates the required revenue."

https://lobste.rs/s/kjvb2i/virtualbox_e1000_guest_host_escap...

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.

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

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?

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.

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.

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

One example: http://www.zerodium.com/program.html

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

So basically, their value.

I wouldn't put it that way. The potential value lost (reputation, downtime, etc) for the vendor could be more than the value an attacker might gain.

It's not a slice of cake that is exchanging hands. The attacker might only be interested in the cherry on the top but he could also destroy the rest of the cake in the process.

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.

It is called darknet :)

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.

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.

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.

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

Yeah. Just look at where we are today. But calling it "perverse outcome" is sugar coating it.

If it wasn't for profit being the king of all (and being the current common sense). Then we would've put more time into making software more secure.

Software not made for profit is very often no more secure.

The problem is not profit, it's that these security issues don't really lower it enough. I've seen the profit motive working very well in a couple of companies when the threat of lowering them (in the form of large fines) appeared thanks to the GDPR.