Slashdot Mirror
Responsible Disclosure — 16 Opinions
An anonymous reader writes, "Disclosure. Just a word, but in the security field it is the root of progress, sharing knowledge and getting bugs fixed. SecurityFocus published an interesting collection of quotes about the best disclosure processes. The article features 11 big vendors, 2 buyers of vulnerabilities, and 3 independent researchers. What emerges is a subtle picture of the way vendors and researchers differ over how much elapsed time constitutes 'responsible.' Whereas vendors ask for unlimited patience, independent researchers look for a real commitment to develop a patch in a short time. Nice read." Wikipedia has an entry for "full disclosure" but none for "responsible disclosure."
It does now.
Media that can be recorded and distributed can be recorded and distributed.
-kfg
It really wasn't so indepth, but it was interesting the statement by each of those companies. The one that impressed me the most was SAP, where the vendor and the researcher would agree on action to be taken at the time of the disclosure.
I do think that the ethical approach is certainly approach a vendor first. Inform them that they have a given time to apply a patch to it, and then hold them to it and release the information at the end of that time.
Justin - Don't be afraid of my blog, it won't bite.
...the decision is easy. Publish the bugs after five days. This should be enough. They proved they can deliver patches after three days.
Seriously, have a look. If you're at all used to reading between the lines, their statements regarding security, disclosure etc give you a far greater insight into their real attitudes than any marketing, reviews or horror stories ever could.
Meta will eat itself
It may be because 'full disclosure' has meaning in the security community, while 'responsible disclosure' does not.
All 'responsible disclosure' is is a set of general ethics and courtesy that security researchers give programmers/companies/entities in order to make an orderly repair of a vulnerability. It is a function of 'full disclosure', not something in of itself.
Slightly related: I've read things that liken 'full disclosure' to yelling "Fire!" in a crowded theater. I tend to think it of yelling "Fire!" in a theater made of flash paper doused in gasoline, while one of the jugglers is preparing to light his flaming torches.
In other words, yelling 'FIRE!' is permissible, if there is actually a high likelyhood of fire...
The responsible vendor takes time to vet the problem within their own lab. They have to develop a patch, [they] Quality Control it and then publish the patch. Microsoft and Oracle average about 120 days to do this.
So, in order to be "responsible" you have to keep the vulnerability secret for 120 days. Four months. You're kiding right? Say I'm an independant researcher. I find this vulnerability using no special skills and publically available tools. Clearly a highly skilled blackhat could just as likely have found the same vulnerability as me. Let's suppose that I've found this vulnerability in the first 2 days of a new release of the product under inspection. The blackhat could well have discovered it in the same number of days, but let's say it takes him a month longer than me, just to be generous. I'm supposed to sit on this vulnerability and let the blackhat break into systems using it for how long? 3 months? This is responsible? Wouldn't it be more responsible if I were to go public immediately? Obviously publishing tools which script kiddies can use to attack people is not a good idea, that's not what we're talking about. Surely I should at least tell people that I have found a vulnerability and that the software in question is not, in my opinion, something that you should be using if you care about security. Isn't my failure to do this just make me complacent in a conspiracy to hide that fact that people may be breaking into systems using this vulnerability?
What if I'm an IDS manufacturer? I start getting alarms that shell code has been detected in a protocol stream that has never before seen shell code in it. Analysing the incident I discover that there is a vulnerability in a particular daemon which these attackers are using to gain unauthorised access. Who should I inform? The vendor of that daemon? My customers? Or the general public? This is no longer a theoretical "the bad guys might know too" situation, this is a widespread pattern of attack that I have detected indicating that real harm is being done. If I fail to inform the public immediately, am I not complacent in helping nto more computers? Doesn't sound very responsible to me.
How we know is more important than what we know.
If I were deciding policy for MS or any other big vendor, I would publish a "hush money" policy on security vulnerabilities.
Basically, it would go like this:
"If you discover a vlunerability and report it only to us, when we eventually release the patch, we will give you credit for discovering it (what researchers really want), and we will give you $10,000. If you report it to anyone else before we release the patch, you will get no money and no credit."
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Sorry, no, that's bullshit. If you wanna make stupid analogies, at least get them right. Calling "Fire!" in a crowded theatre is absolutely perfectly ok, if there is a fire. However, if you know there is a fire and know that people will, sooner or later, get burnt, going for a stroll to the front office and asking to talk to the manager, tell him there is a fire, and have him say "Yeah, we'll get to that in about 120 days, on average" is not ethical. It's not responsible. It's participating in a conspiracy that belittles the people in the theatre and hampers their ability to make a valid risk assessment.
How we know is more important than what we know.
Well, I certainly wouldn't want to install anything that comes out of MS after only 5 days. History tells us that the consumer-related bugfixes take at least 30 days, only industry-benefitting fixes come out over night.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Well, there may be a middle ground between full disclosure and no disclosure. In certain situations you might be able to just disclose the danger and how to avoid it, without actually disclosing enough details for black hats to exploit it (although it of course gives them a hint where to search).
For example, "If you don't absolutely need it, switch off functionality X in product Y. I've found a serious vulnerabily in Y which is only effective if the option for X is set. An attacker might take control over your computer."
This would explain what the users need to know (activating X in Y currently is dangerous), without providing information which wouldn't help them (because they can't fix X anyway), but would help the black hats.
The Tao of math: The numbers you can count are not the real numbers.
Give em 30 days at least.
r osoft_and_f.html
Why? MS has proven it can fix a hole which allows reading of its DRMd content in 3 days.
http://www.schneier.com/blog/archives/2006/09/mic
"The more prohibitions there are, The poorer the people will be" -- Lao Tse
From a study reported on in the WSJ back in January, and elaborated on later, Microsoft's time to patch vulnerabilities they classify as "critical" has risen 25% since 2003, to 134 days. Except, however, in the case of full-disclosure vulnerabilities, where details and almost always proof-of-concept code were released to the general public. For those vulnerabilities, the time to fix fell from 71 days in 2003 to 46 days in 2005. Based on the data, full disclosure does in fact accelerate the fix and the problems aren't being addressed in a reasonable timeframe without it (4 months for a self-classified critical vulnerability isn't particularly timely).