Hacker News Reader

Comment by nkantar | Hacker News Reader

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.

View on HN

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

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

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.

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

Reply on news.ycombinator.com