Hacker News Reader

Comment by mehrdadn | Hacker News Reader

Disclosing when a patch is NOT provided should motivate prompt patches. Nobody is disputing that. But you're saying disclosure when a prompt patch IS provided motivates patches further, and that's not even just a guess? How...?

View on HN

As soon as a patch is released, it should be presumed that bad guys know all the fixes in it. Once a patch is released, people with bad intentions study all the changes (source code for open source, and decompiling for closed-source) and find all the changes that were made, looking for opportunities to exploit.

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

So here's what I don't get. Even if you put an N-month delay between the disclosure and the patch, people would still have to update their systems far more regularly, because patches from older exploits would still have their disclosure deadlines expiring, and the motivation you claim should still exist for them. So why can't you just put the N-month delay? Are customers really going around updating regularly but actively filtering the list of updates you provide to include only the ones that haven't had their disclosure deadlines passed?

You're missing the key point: the patch is disclosure to the bad guys.

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?

I'm not missing that point. "Which is better" is not measured by who has "information". If only the bad guys have the information, but they still fail to exploit, that'd be an awesome world. Somehow infosec folks seem to keep treating this as an information game rather than a security game.

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?

FWIW, I am much less likely to procrastinate on an update if I know it fixes a vulnerability.

On an update in particular? Or on the set of updates being applied to your system at a given time, if one of them fixes a vulnerability? (Do you filter out the ones that don't?)

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.

> Do you filter out the ones that don't?

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.

There's a little box that occasionally pops up in the top right corner of my screen. I usually just click "remind me tomorrow" ad infinitum. But if I find out there's an important vulnerability that an update fixes, I go out of my way to update immediately. That's all I'm saying.

Information asymmetry is a key part of security - users not having information clearly does not make them more secure.

As noted elsewhere, patches are effectively disclosures, with some small delay (best described as an obscurity delay) baked in.

Customers are going around and delaying updated that aren't marked as critical because it's too much trouble, and might be included in a large quarter/half/full year patch roundup with an OS update.

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

Most users aren't updating at all. My highly educated STEM employed wife just hits the "not yet" button on all updates. But when disclosures get enough attention that it leaks into the broader (not-security focused) information ecosystem, people are more likely to upgrade- remember how suddenly everyone heard about Heartbleed (e.g. my mother-in-law asked me about it)? That's because for all that we steely-eyed engineers said "cute names? Logos? This is fake, it's all about the ideas, not the fluff" that fluff caused the message to be amplified and more white hats learned that they needed to upgrade. The bad guys knew immediately, because they are paying attention. Most of the good guys aren't, because they are busy earning a living that, fortunately for them, doesn't revolve around computer security.

What you say seems plausible, but it's not clear to me if it's actually true or false. Heartbleed is a tough example, because it's already entirely open-source, so it's not really possible to imagine "how much media coverage would it have gotten if the security researchers themselves didn't publish a PoC". (I don't even recall if they ever did provide one.)

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.

Like you, I suspect, I am not in a position to do this sort of analysis. But I would note that Qualys didn't release a PoC with their announcement of the Exim bug, the RCE takes 7 days to trigger (you need to send a keep-alive packet every 4 seconds for 7 days as a step in the exploitation), and within 8 days of it being published it was being exploited in the wild. So the bad guys move fast, even without a PoC.

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.

Hm... are you sure you're not misreading the timeline and what happened?

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

> But you're saying disclosure when a prompt patch IS provided motivates patches further, and that's not even just a guess? How…?

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)

> 1. because the policy is "mandatory disclosure", it's way harder to criticise it if it's a blanket, universal policy

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

Seems like the disconnect between you and others is your assumption there is some time gap of knowledge about the exploit after the patch is released.

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?

Yes, but a time gap of knowledge is just one dimension, whereas I see a gap in every other dimension too. I expect that not every bad actor who would learn from a PoC would learn from a binary, not every one who would learn that actually invest the time to write an exploit, not every one who invests the time would actually come up with an exploit in such a short timespan, and not everyone who does all that will target the same set of customers. Furthermore, as I said in another comment, the existence of prior patches would mean people would still have to update regularly because those disclosures would be expiring anyway, so it's not at all clear to me adding a delay would change that. And there are probably other dimensions I can't think of right off the top of my head.

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 someone might discover it someday?

because many people will discover it immediately by looking at the patch.

Disclosure motivates people to apply the patches.

Reply on news.ycombinator.com