6 ms·

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 m

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

masklinn 7y ago
> 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)
- mehrdadn 7y ago
  > 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...
  - PKop 7y ago
    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?
    - mehrdadn 7y ago
      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.
      - deleted 7y ago
        [deleted]
  - minitech 7y ago
    > because someone might discover it someday? because many people will discover it immediately by looking at the patch.
mandevil 7y ago
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-wizard-rce-exim.txt https://www.qualys.com/2019/06/05/cve-2019-10149/return-wiza...
- mehrdadn 7y ago
  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?
  - 3JPLW 7y ago
    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?
philwelch 7y ago
Disclosure motivates people to apply the patches.

masklinn 7y ago

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

mehrdadn 7y ago
> 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...
- PKop 7y ago
  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?
  - mehrdadn 7y ago
    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.
    - deleted 7y ago
      [deleted]
- minitech 7y ago
  > because someone might discover it someday? because many people will discover it immediately by looking at the patch.

mandevil 7y ago

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-wizard-rce-exim.txt https://www.qualys.com/2019/06/05/cve-2019-10149/return-wiza...

mehrdadn 7y ago
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?
- 3JPLW 7y ago
  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?

philwelch 7y ago

Disclosure motivates people to apply the patches.