Hacker News Reader

Comment by Coding_Cat | Hacker News Reader

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

View on HN

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

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

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.

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

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.

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.

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

[1] https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29

Interesting — I had no idea of those "side effects". Thanks for the links!

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Hours can be really useful, especially if they can be scheduled in advance.

Reply on news.ycombinator.com