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.

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.

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.

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

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?

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