6 ms·

I agree with Leif here. Sure releasing a PoC serves a purposes even in these cases, but this is just idiotic. One cannot expect outsiders to patch their systems

I agree with Leif here. Sure releasing a PoC serves a purposes even in these cases, but this is just idiotic. One cannot expect outsiders to patch their systems this quickly. I would release without a PoC for a few weeks, maybe a month depending on how widespread the exploit is believed to be, to give everyone enough time to update. Humans need sleep , and some patches need downtime after all. Perhaps a tiered release would be best? Release a PoC to a few trusted partners to verify and pen-test the new patches before giving a full-disclosure. If there's something I'm missing here I'd love to hear it, cause frankly I feel like I'm just stating the obvious here...

nkantar 11y ago
> If there's something I'm missing here I'd love to hear it, cause frankly I feel like I'm just stating the obvious here... Likewise — I'm very much a n00b sysadmin, but I'm having a tough time understanding how giving people a buffer isn't desirable.
- Titanous 11y ago
  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.
      - 11y ago
  - 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.
- danielweber 11y ago
  The security community, like any community, loves things that increase its status. A bunch of stuff getting compromised because Idiot Software Company Couldn't Write Secure Software and making national news increases the status of the community. It's an uphill fight against basic human group dynamics.
- bowlofstew 11y ago
  So unfortunately the people that you as a sysadmin are protecting against don't care about your need for a buffer to update systems. Once the patch release is out there, the exploit writers know the target and can just create the exploit quickly without a PoC.
x0x0 11y ago
I think the fundamental misunderstanding is that once a patch is released, you've given hackers a roadmap to understanding the exploit. At this point, there are essentially professional dev teams waiting to build out exploits. From what I've read, lack of a full poc delays hackers by hours.
- Coding_Cat 11y ago
  While I certainly think it's true that the "real deal" would jump on any patches put out and reverse-engineer the exploit with relative ease, I expect the actual hack scene to have the same distribution of skill (if not more skewed) than the regular programming world. For every Carmack there are 10 me's, and for every professional exploit builder there is an army of script kidies. Look at how widespread Shellshock and Heartbleed exploits became after their disclosure, I don't think there are that many attackers capable of making such an attack themselves without a PoC.
  - x0x0 11y ago
    True -- but skilled engineers aren't necessary. The exploit builders sell their wares. I read recently -- unfortunately I don't have the link handy -- that these exploit toolkits rent out for eg $5k/mo.
  - Titanous 11y ago
    No PoC was released with the Heartbleed disclosure, but many were published within hours by others (including myself). And this was a good thing, without them admins would be unable to verify that their servers were patched successfully.
    - zorked 11y ago
      At a company where I worked previously one team only noticed one of their systems hadn't been correctly patched against Heartbleed because there was an exploit available that they could use to test. Who knows what would have happened days/weeks/months later if that hadn't been the case.
- 11y ago
pg_is_a_butt 11y ago
one cannot expect to keep using shitty software with backdoors built in. FIX IT, OR WE'LL TELL PEOPLE. the date was prearranged... fix it sooner, or better yet DON'T WRITE BUGS IN THE FIRST PLACE, MORONS. ain't nobody got time for that.

nkantar 11y ago

> If there's something I'm missing here I'd love to hear it, cause frankly I feel like I'm just stating the obvious here... Likewise — I'm very much a n00b sysadmin, but I'm having a tough time understanding how giving people a buffer isn't desirable.

Titanous 11y ago
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.
    - 11y ago
- 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.
danielweber 11y ago
The security community, like any community, loves things that increase its status. A bunch of stuff getting compromised because Idiot Software Company Couldn't Write Secure Software and making national news increases the status of the community. It's an uphill fight against basic human group dynamics.
bowlofstew 11y ago
So unfortunately the people that you as a sysadmin are protecting against don't care about your need for a buffer to update systems. Once the patch release is out there, the exploit writers know the target and can just create the exploit quickly without a PoC.

x0x0 11y ago

I think the fundamental misunderstanding is that once a patch is released, you've given hackers a roadmap to understanding the exploit. At this point, there are essentially professional dev teams waiting to build out exploits. From what I've read, lack of a full poc delays hackers by hours.

Coding_Cat 11y ago
While I certainly think it's true that the "real deal" would jump on any patches put out and reverse-engineer the exploit with relative ease, I expect the actual hack scene to have the same distribution of skill (if not more skewed) than the regular programming world. For every Carmack there are 10 me's, and for every professional exploit builder there is an army of script kidies. Look at how widespread Shellshock and Heartbleed exploits became after their disclosure, I don't think there are that many attackers capable of making such an attack themselves without a PoC.
- x0x0 11y ago
  True -- but skilled engineers aren't necessary. The exploit builders sell their wares. I read recently -- unfortunately I don't have the link handy -- that these exploit toolkits rent out for eg $5k/mo.
- Titanous 11y ago
  No PoC was released with the Heartbleed disclosure, but many were published within hours by others (including myself). And this was a good thing, without them admins would be unable to verify that their servers were patched successfully.
  - zorked 11y ago
    At a company where I worked previously one team only noticed one of their systems hadn't been correctly patched against Heartbleed because there was an exploit available that they could use to test. Who knows what would have happened days/weeks/months later if that hadn't been the case.
11y ago

pg_is_a_butt 11y ago

one cannot expect to keep using shitty software with backdoors built in. FIX IT, OR WE'LL TELL PEOPLE. the date was prearranged... fix it sooner, or better yet DON'T WRITE BUGS IN THE FIRST PLACE, MORONS. ain't nobody got time for that.