“Why are you releasing a full exploit just minutes after the patch is released?”
openwall.com
openwall.com
Likewise — I'm very much a n00b sysadmin, but I'm having a tough time understanding how giving people a buffer isn't desirable.
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).
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.
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.
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
Time to respond is always valuable. Amateurs rushing out patches can cause as many problems as buggy software, especially if the patches are buggy.
4) There is some fame in being the first to publish a full exploit. Not as much as publishing a vulnerability, but still.
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.
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.
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.
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.
Who knows what would have happened days/weeks/months later if that hadn't been the case.
You'll be rewarded with some really great discussion!
It's also a 90s style Unix file management bug. It's not like patches and vague advisories were going to keep the exploit under wraps.
That doesn't make it unreasonable to complain about exploits being released in advisories (though: this is a complaint that is approximately as old as security advisories), but it should dampen the outrage a bit.
/r/netsec has some good discussion: https://www.reddit.com/r/netsec/comments/3ed4fu/cve20153245_...
One choice puts a lot of risk on the users of software. One choice puts way less. You're constantly encouraging putting more risk on users and exploits into arbitrary attackers' hands with the argument that one or more attackers might already be a risk. That makes no sense. The only people with a straight-up benefit from this are malware writers who don't want to work very hard converting the patch into an exploit.
Researchers should delay the publishing of exploits at least a week so people can test and deploy the patch. I keep mentioning testing because patches sometimes break stuff themselves. Doing otherwise just saves attackers work.
Instead, you want to acquire immediate vulnerability to a large group of hackers to prevent a patch from maybe making you vulnerable to a smaller number that either has an existing exploit or RE'd the non-working patch to devise a new one. Makes no sense lol... Better to get the patch, do basic tests to ensure it doesn't break functionality, install it, monitor the system/network, and then verify the security later when the sploit is released.
What they did here was simply irresponsible at best.
If you want to get rid of the False Sense Of Security, announce that there are working exploits out there.
This also prevents users from being able to test their machines vulnerability after patching to verify that the patch remedies the problem in their installation. Again, apply the patch, hope that it works in my installation (with my config options) is a piss poor security policy.
This assumes a bunch of stuff about the psychology of everyone else that you cannot possibly know.
You are making decisions for other people because you think you know their business better than they actually do.
> This is a sense of security
You are not a telepath who can read people's minds.
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.
I'm not asserting that there are not negative aspects, but in the majority of cases waiting for some indeterminate time before releasing a PoC or not releasing one at all is net negative.
This is essentially a rehashing of the Microsoft/Google squabble a few months ago.
Google didn't release PoC exploit code the same instant as Microsoft released the fix.
Releasing an exploit simultaneously with the patches gives people zero time to patch. In that sense it somewhat defeats the purpose of the embargo.
Maybe it's worth releasing not a simple PoC, but an unnecessarily large ball of executable or testing procedure that incorporates the PoC for testing purposes, but also does many harmless, exploit-like but nonsensical things, performing only one action that matters (the test.) A hairball of mostly trash code or procedure that is not trivial to untangle, in other words.
The idea is to create enough of a mess to stop the script kiddies from quickly knowing what to modify for their own purposes, not forever; but for a time.
Just maybe it would be possible to create a hairball that takes longer to untangle or trace than just having a pro tear apart the patch and roll their own attack, ignoring the hairball. If so, providing the test/PoC/hairball is not giving the pros in the black hats any extra time. (But in any case, at least you are not amusing all the script kiddies.)
If you can make a worthy hairball, you might just want to release the hairball just a little ahead of the patch; enough to whet admins' appetites for the patch - inverting the current order of release. (Or not.)
Again, this may not be practical in all cases or any; and my apologies if that's so.
PS There may be an argument in here for providing an "unnecessarily" and complex patch, too, to make it harder to reverse engineer - perhaps worth considering.
I agree, it would be nice to wait a little while for people to get their patches installed. But also, people like to have a way to verify that the patch worked.
Responsible disclosure is intended to be ethical, the opposite is ... well, irresponsible.
I've worked with irresponsible security disclosurists before, and even those that agree to a window only to dump another small variation after the window is up - rather than working to make sure the product is as good as it could be.
Giving end users time to patch so they are not owned is quite a ethical thing to do. The end goal is less compromised systems.
Doing this at the same time achieves the opposite effect and increases the amount of compromised systems.
It's never been "we're giving you two weeks, get it done fast because the exploit is going out then", it should be "we'll give you enough time to fix this properly, and then give the customers time to update once announced".
I personally would always release when something got done early, just because the person on the other end is usually unpredictable. However, the person on the other end shouldn't assume development of the fix didn't take the full interval.
Let people pen-test after they had a chance to update to secure the systems. Having the ability to prove a fix is not worth systems being owned prior to being able to fix them. The damage is already done at that point.
I've worked a lot of CVE reports, and about half the time, the person on the other end just wants credit, they aren't really going to hang around and try to help, and often they supply terse information (i.e. no exploit PoC to the vendor) as some form of game. I'd much rather this always be more user focused, the ultimate desire should always be to help the end user, and often users are less educated and don't have dedicated security teams.
If vendors want "responsible disclosure", they can simply buy exploits at market value.
The value to a sufficiently motivated black-hat organisation is surely far higher than the value to any one user of MariaDb, no matter how big they are.
It turns out the name was chosen for its connotations, i.e. to sound good. If you call it "coordinated disclosure" it doesn't come into the discussion cheating.
I personally view it as irresponsible regardless of whether we called it "Foo Disclosure". I do view sharing the exploit on the patch date irresponsible irrespective of the term. I believe the name was chosen well, and I don't think it deserves painting with "PATRIOT ACT" type brush.
I've dealt with commercial firms as well as non-commercial firm disclosures, and really working with people who report security issues could go a LOT smoother. A lot of those experiences did not go well, but it would be wrong for me to make generalizations.
Business here on either side doesn't matter; the user is all that matters, and it shouldn't be about getting "credit", earning points, or being done with something quickly. I think a lot of people think this is a game or something, and it's really not.
Real systems and real people's data are on the line.
Many researchers do share and coordinate, as a courtesy to the whole community. But the idea that they're obliged to is a little disquieting.
If vendors want to ensure that they get some control over the release schedules on their flaws, they can do what Google does and pay a shitload of money to build internal teams that can outcompete commercial research teams. Large companies that haven't come close to doing that shouldn't get to throw terms like "responsible disclosure" around too freely.
1) Actively exploit - I think we can agree that providing it to someone who will actively exploit is ethically dubious, or at least can be classified as irresponsible?
2) Share with the vendor. Ethically, this is fine.
3) Do nothing with it. Ethically, this is fine, although pointless.
4) If you make software that's supposed to detect and/or block the use of such vulnerabilities, add it to the detection system. I don't think this is a 'good guy' thing to do, although I suppose it could in principle be what's best for the company.
Having said that, my guess is that this last one has the smallest amount of commercial value, since it turns what might be a few months of work into a tiny part of a bigger piece of software; it's an investment that probably ranges (when overheads are considered) from $5-50k that has no value at all unless someone else finds the same bug.
But if someone else finds the bug, they could as easily be another security researcher as a bad guy, and then you've kinda lost out.
Have I missed anything here?
The general response a lot of vuln researchers have to this kind of sniping is that it should be directed to the person who wrote code after, say, 1995 that directly edited /etc/passwd instead of rebuilding and linking it.
http://www.openwall.com/lists/oss-security/2015/07/23/19
"That's how coordinated release dates work. Instead of trying to shame Qualys for not following your arbitrary views on what is and isn't "Responsible Disclosure", perhaps you should make sure Red Hat releases patches hours before the CRD, like Ubuntu does?"
The rest is the usual rehashed discussion on this topic.
"Ubuntu is actually very careful to not release anything ahead of CRD unless the CRD is broken elsewhere. Not saying we've never made a mistake, but as you can imagine it is quite annoying when a CRD is broken-- we certainly don't want to be the cause of that annoyance for others. :)"
We could end up repasting the entire thread, but the very next comment is from Ubuntu denying that behavior. Releasing early is basically violating the embargo.
Reading the entire thing is worthwhile.
if to have real security we must prove that bad guys do not have an exploit, would that not lead to a conclusion that there is no real security at all? it is safe to assume that exploits for undisclosed vulnerabilities exist. and, regarding the "several hours" argument, didn't the release of the exploit reduce those several hours to zero? instead of not being sure if the bad guys have the exploit, or if they will develop it in 1 or 3 hours, we are now certain that they have it. instead of a sense of false security, we currently have no security.
it seems obvious that little to nothing can be done about those who already have the exploit. and given the wide agreement that developing it will take a couple of hours, then wouldn't an optimal exploit release time be 1-2 hours?
and as far as i could notice, only one very downvoted comment mentions that a motivating factor for a quick release could be to be the first to break the news. certainly sounds like good PR for a security company. why is this unspeakable? :)
A lot of the analysis in the comments here does not seem to be taking all of these requirements into account. They are particularly relevant in this case because, I believe, the exploit is a local privilege escalation for people with shell access.
> [W]ithout the threat of full disclosure, responsible disclosure would not work, and vendors would go back to ignoring security vulnerabilities.
https://www.schneier.com/blog/archives/2012/06/on_securing_p...