If you want to get angry about this, get angry at the vendor that took your money and time and attention and gave you a product with an exploitable security vulnerability in it. I think the issues involved here are a bit subtle to warrant knee-jerk anger, but if you've got to get angry, at least get angry in the right direction.
This happens to 100% of MS Windows Patch Tuesday patches, and happens to less well known products as well. These examinations happen even on changes that aren't known to be security problems when they are fixed: the recent EXIM worm problem was actually fixed by the EXIM team as a minor bugfix, and they didn't categorize it as a security flaw. It was only when outsiders at Qualys [1] saw the change that they realized it was possible to do a remote command execution.
In essence, the bad guys are patient, smart, and observant. They will notice all of these code changes. So disclosing the problem after it is patched serves to encourage users to patch, because it boosts and amplifies the "get updated" signal for the good guys, and the bad guys already are paying attention.
[1]: https://www.qualys.com/2019/06/05/cve-2019-10149/return-wiza...
The P0 disclosure is the disclosure to the good guys and users.
You're assuming that the bad guys are learning about the problem from P0's disclosures, but without P0's disclosures, the bad guys would still learn about the old bugs from the patch itself.
So which is a better situation: a world in which only the bad guys get the information about broken old versions, or a world in which everyone gets the information?
The way I'm suggesting you measure "better" by measuring actual hacks, and how the number of actual hacks is changing based on whether you insert a delay or not.
So we go back to my question above, which you didn't address. I'm saying the fact that patches come out on a regular basis means that people would still have to update regularly, even if each individual patch comes with a delay before a PoC etc. is disclosed. So I repeat the question: would customers really update regularly but actively filtering out patches whose disclosure deadlines haven't passed? If not, why wouldn't the delay that still achieve the outcome everyone is asking for here?
As noted elsewhere, patches are effectively disclosures, with some small delay (best described as an obscurity delay) baked in.
And wouldn't a vulnerability still be there even if there wasn't e.g. a PoC disclosed? I'm not really sure how that affects what I'm saying.
Of course not, that's a straw man that only you are suggesting and often isn't even possible on most systems. People by-and-large will apply all pending updates at once.
Responsible disclosure pushes folks to update. Well, that and new emojis that they're feeling FOMO from. It's a carrot and stick sort of operation.
On the other hand, I'm pretty sure I've repeatedly seen patches on closed-source products (from Microsoft, Apple, etc.) make it to the broader news without a PoC, so to me it seems like it's really a function of how severe the vulnerability is (although every vulnerability becomes more severe when it comes with an exploit and an instruction manual).
There's an easy way to settle this with data though. Is there data to indicate fewer machines are actually hacked at the end of the day when a PoC is provided after a patch, compared to when it is not provided unless the vendor doesn't issue a patch? That's what ultimately matters at the end of the day, and I'd readily buy that, but I have yet to be made aware of any.
Based on evidence like that, I don't think that a PoC matters that much to the most dangerous bad guys. The script kiddies, maybe it does matter, but there are enough NotScriptKiddies out there that'll own you just as hard with Shodan and their own code that the marginal effect of releasing a PoC is probably pretty minor.
Because as far as I can tell, Qualys did include precise exploit details [1], and the attacks happened 8 days after they did that, meaning in fact the inclusion of source code details would have caused the exploitations in the wild!
Here's the timeline I can find:
CISA reported this vulnerability as being exploited in the wild on June 13 [2]. According to a June 14 article [3], this came one week after Qualys disclosed the bug, which means they must've been referring to the the announcement Qualys made on June 5 [1]. When you look at that announcement, it in fact included full details on how to exploit the vulnerability ("a local attacker can simply send a mail to [...] and execute arbitrary commands") on top of explaining in precise detail the vulnerable piece of code in the (open-source!) source code.
More info on the timeline is in [4]. They refer to a May 27 report, which I cannot find online. I assume it must've been a private disclosure. In any case, it doesn't seem to be what SCMagazine was referring to, given CISA only reported this on June 13 and SCMagazine referred to that on June 14.
So... if I'm reading this right, it seems in fact it almost certainly was the precise exploit details that made the bad guys move quickly. Right?
[1] https://www.qualys.com/2019/06/05/cve-2019-10149/return-wiza...
[2] https://www.us-cert.gov/ncas/current-activity/2019/06/13/Exi...
[3] https://www.scmagazine.com/home/email-security/exim-vulnerab...
[3] https://www.exim.org/static/doc/security/CVE-2019-10149.txt
It's in the interest of the developer to downplay security problems they they think aren't a problem. It's in the interest of the security researcher to make sure they get the information about how problematic the exploit is. The user can only make an informed decision about whether an update is important when they have the information.
Once the patch is released, all announcing the exploit does is possibly bring more exposure to it for people that might have delayed or foregone patching, possibly causing them to patch manually or request their automatic patch process run immediately instead at some future date.
This is a net gain for the security of individuals, in that it likely causes some number of people to patch earlier than they would have, and adversaries are already actively tracking patches so it's unlikely you've given away much info they couldn't get fairly easily (and they are incentivized to find it no matter what).
1. because the policy is "mandatory disclosure", it's way harder to criticise it if it's a blanket, universal policy
2. disclosure is important for users (in general though mostly corporate) because if the issue is not publicly disclosed they might not update their systems (assuming issues are minor or irrelevant)
"It's harder to criticize"? So the reason to put users at risk is to... solve a PR problem?
> 2. disclosure is important for users because if the issue is not publicly disclosed they might not update their systems
Hold on. You're actively injecting a threat and guaranteeing that everyone knows the exploit immediately and that it can be deployed by lots of people on a wide scale because someone might discover it someday?
Can't you just at least easily address this by at least putting a reasonably long time gap between the patch and the disclosure? People will still have to update their systems in the interim due to previous patches' deadlines expiring...
Others have stated that almost immediately after patches are released they are reverse engineered to discover the exploits. So at that time, motivating people to upgrade to the patch is all benefit no?
If they're wrong about their assumptions, you might have a point. If you're wrong, what's the dispute?
There should be an easy way to settle this, which is with data, which I have not yet seen anyone point to. I would be shocked if data showed that the number of actual customer systems hacked actually decreases when a PoC is provided quickly after a patch, vs. when this is not the case.
because many people will discover it immediately by looking at the patch.