4 ms·

1) It helps admins verify that the patch was successfully applied. 2) It gives security researchers more surface area to evaluate when looking for similar bugs

1) It helps admins verify that the patch was successfully applied. 2) It gives security researchers more surface area to evaluate when looking for similar bugs or bugs in the patch. 3) A PoC not existing provides a false sense of security. Just because one is not published does not prevent attackers from creating and using an exploit (in many cases before the vulnerability is disclosed).

dimman 11y ago
Again, delaying the PoC exploit code release gives people some time to patch their systems. How much time depends on the skill of the attacker and complexity of the exploit, but some time is better than no time.
- Joky 11y ago
  And again the point of Titanous is that delaying the PoC provides a false sense of security. Saying "some time is better than no time" is the problem, you have a false impression that you have time while the fact that the PoC is not published does not mean it is not already used by some attackers. Delaying does not provide an incentive to people to update. I agree that there is a tradeoff, but it is not a simple a you present it (delaying means giving some time).
  - EmanueleAina 11y ago
    It's not a matter or "impressions" but rather the matter of chance: when a vulnerability is published you may have the chance to fix it before someone figures how to use it in a exploit. If the exploit is released immediately, that chance becomes effectively nil. Of course this doesn't change the fact that everybody should apply the patch ASAP, but delaying the exploit simply adds some delay to the bad guys.
nkantar 11y ago
All of those make sense, but they seem to focus mostly on the most skilled of both groups. I don't have any useful numbers, but that seems to leave many novice sysadmins vulnerable to script kiddies simply due to not being around right at the patch release time. I could be wrong, though. And even if I'm not, perhaps it makes more sense to do things this way, but I'm not (yet) convinced.
- Titanous 11y ago
  Shellshock and Heartbleed both provide good examples of why public exploit code is a net good thing. Researchers put Shellshock proof of concept exploit code into fuzzers[0] and managed to find five more bugs subsequently[1]. Heartbleed required a patch to OpenSSL, which is typically a dynamic library. I'd wager that without publicly available exploit code to test with many admins would have just installed the patch and failed to restart the server processes, leaving their systems vulnerable. The solution to improving patch deployment timelines is automated updates, not having admins always online. Admittedly this is still an area that is underdeveloped. [0] http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-... [1] https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29 https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29
  - nkantar 11y ago
    Interesting — I had no idea of those "side effects". Thanks for the links!
  - nickpsecurity 11y ago
    So, someone with such an exploit couldn't have done that a week or two later to give people time to patch? Plus, you've released a few, unusual examples where the vast majority of patches are to vanilla vulnerabilities in software that provide us little, learning experience. Saving attackers labor while increasing risk on defenders isn't good for security. Time to respond is always valuable. Amateurs rushing out patches can cause as many problems as buggy software, especially if the patches are buggy.
  - dev-da0 11y ago
    If a patch can be made by upstream in good faith to addressa vuln before CRD, embargoing until after its users have had a reasonable chance to deploy it is a very good thing. If the upstream is not responsive, that's different. The point is not artificially creating fires and surprises unnecessarily, which put thousands or millions of systems at avoidable risk. Patches need to get out there as soon as possible when good faith is working and PoCs need to be released anyhow if upstream is unresponsive. This accountability will ensure that preventative, cooperative fixes are released as soon as possible with minimum damage. Because of a premature PoC were used to takedown life/safety or major business concerns, there will be additional fallout. Playing fast and loose and dismissing concerns of large-scale installed bases is not a strategy, it's either ignorance or hubris. Causing emergencies and putting people unnecessary risk is nearly always preventable bullshit. There are only a few cases where upstream developers are unable, incapable or unwilling to patch something in good faith that it should be released... And in some cases where the fix is tricky, there should be an occasional, mutually-agreed short deferment. Again, avoid unnecessary harm to users by applying common sense rather than unrealistic dogma "full disclosure right now, fuck everyone else."
cies 11y ago
> > I'm having a tough time understanding how giving people a buffer isn't desirable. 4) There is some fame in being the first to publish a full exploit. Not as much as publishing a vulnerability, but still.
mzs 11y ago
For 1, in this case a much simpler script that verifies if newline can be added or not would have been sufficient. For 2, not releasing a PoC could be even better. Someone else from the advisory might come-up with an even more clever angle. With the PoC released and it being so intricate, there is less motivation, so less surface area is explored in this case. For 3, yes it's always false sense, that's why the PoC release being delayed should not influence any appropriate reactions anyway.
tzs 11y ago
1) How often do patches fail to apply successfully in a way that does not generate an error message from the patch management system? 2) How many security researchers actually start doing this so soon after the PoC is released that delaying the PoC by a short time (even a day would greatly help many admins) would have any effect on them? 3) This is a good argument against a long delay in releasing a PoC. I don't see how it is relevant to a short, pre-announced, delay. It is unrealistic to expect every vulnerable system in the world to be patched at the same time, immediately after the patch is released.
- tptacek 11y ago
  1) Not very often. 2) In this case, probably none. 3) The real false sense of security in this case is the notion that the patch obscures the bug meaningfully more than the exploit code does.

dimman 11y ago

Again, delaying the PoC exploit code release gives people some time to patch their systems. How much time depends on the skill of the attacker and complexity of the exploit, but some time is better than no time.

Joky 11y ago
And again the point of Titanous is that delaying the PoC provides a false sense of security. Saying "some time is better than no time" is the problem, you have a false impression that you have time while the fact that the PoC is not published does not mean it is not already used by some attackers. Delaying does not provide an incentive to people to update. I agree that there is a tradeoff, but it is not a simple a you present it (delaying means giving some time).
- EmanueleAina 11y ago
  It's not a matter or "impressions" but rather the matter of chance: when a vulnerability is published you may have the chance to fix it before someone figures how to use it in a exploit. If the exploit is released immediately, that chance becomes effectively nil. Of course this doesn't change the fact that everybody should apply the patch ASAP, but delaying the exploit simply adds some delay to the bad guys.

nkantar 11y ago

All of those make sense, but they seem to focus mostly on the most skilled of both groups. I don't have any useful numbers, but that seems to leave many novice sysadmins vulnerable to script kiddies simply due to not being around right at the patch release time. I could be wrong, though. And even if I'm not, perhaps it makes more sense to do things this way, but I'm not (yet) convinced.

Titanous 11y ago
Shellshock and Heartbleed both provide good examples of why public exploit code is a net good thing. Researchers put Shellshock proof of concept exploit code into fuzzers[0] and managed to find five more bugs subsequently[1]. Heartbleed required a patch to OpenSSL, which is typically a dynamic library. I'd wager that without publicly available exploit code to test with many admins would have just installed the patch and failed to restart the server processes, leaving their systems vulnerable. The solution to improving patch deployment timelines is automated updates, not having admins always online. Admittedly this is still an area that is underdeveloped. [0] http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-... [1] https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29 https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29
- nkantar 11y ago
  Interesting — I had no idea of those "side effects". Thanks for the links!
- nickpsecurity 11y ago
  So, someone with such an exploit couldn't have done that a week or two later to give people time to patch? Plus, you've released a few, unusual examples where the vast majority of patches are to vanilla vulnerabilities in software that provide us little, learning experience. Saving attackers labor while increasing risk on defenders isn't good for security. Time to respond is always valuable. Amateurs rushing out patches can cause as many problems as buggy software, especially if the patches are buggy.
- dev-da0 11y ago
  If a patch can be made by upstream in good faith to addressa vuln before CRD, embargoing until after its users have had a reasonable chance to deploy it is a very good thing. If the upstream is not responsive, that's different. The point is not artificially creating fires and surprises unnecessarily, which put thousands or millions of systems at avoidable risk. Patches need to get out there as soon as possible when good faith is working and PoCs need to be released anyhow if upstream is unresponsive. This accountability will ensure that preventative, cooperative fixes are released as soon as possible with minimum damage. Because of a premature PoC were used to takedown life/safety or major business concerns, there will be additional fallout. Playing fast and loose and dismissing concerns of large-scale installed bases is not a strategy, it's either ignorance or hubris. Causing emergencies and putting people unnecessary risk is nearly always preventable bullshit. There are only a few cases where upstream developers are unable, incapable or unwilling to patch something in good faith that it should be released... And in some cases where the fix is tricky, there should be an occasional, mutually-agreed short deferment. Again, avoid unnecessary harm to users by applying common sense rather than unrealistic dogma "full disclosure right now, fuck everyone else."

cies 11y ago

> > I'm having a tough time understanding how giving people a buffer isn't desirable. 4) There is some fame in being the first to publish a full exploit. Not as much as publishing a vulnerability, but still.

mzs 11y ago

For 1, in this case a much simpler script that verifies if newline can be added or not would have been sufficient. For 2, not releasing a PoC could be even better. Someone else from the advisory might come-up with an even more clever angle. With the PoC released and it being so intricate, there is less motivation, so less surface area is explored in this case. For 3, yes it's always false sense, that's why the PoC release being delayed should not influence any appropriate reactions anyway.

tzs 11y ago

1) How often do patches fail to apply successfully in a way that does not generate an error message from the patch management system? 2) How many security researchers actually start doing this so soon after the PoC is released that delaying the PoC by a short time (even a day would greatly help many admins) would have any effect on them? 3) This is a good argument against a long delay in releasing a PoC. I don't see how it is relevant to a short, pre-announced, delay. It is unrealistic to expect every vulnerable system in the world to be patched at the same time, immediately after the patch is released.

tptacek 11y ago
1) Not very often. 2) In this case, probably none. 3) The real false sense of security in this case is the notion that the patch obscures the bug meaningfully more than the exploit code does.