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."
What - no quote from Cisco?
"We are all geniuses when we dream"
- E.M. Cioran
I see no good reason not to.
SecurityFocus published an interesting collection of quotes about the best disclosure processes.
Full Disclosure is the only way to go. It's worked brilliantly for Jason Fortuny, my new Hero!
Wikipedia has an entry for "full disclosure" but none for "responsible disclosure."
:)
Well, after tens of thousands of Slashdot nerds read this, I'm sure that'll change in a few minutes.
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.
If there is really a fire, or a likelihood of a fire, you should inform the management so they can make an announcement that doesn't set off panic, which could lead to people being trampled to death.
In the case of security announcements, publicly disclosing a vulnerability before the vendor has been given time to get a patch out actually can cause a fire, because disclosing the vulnerability also allows anyone to create an exploit for the vulnerability.
In essence, full disclosure isn't as bad as shouting "Fire!" in a crowded theater. It's like being in a theater made of flash paper doused in gasoline, and then giving an arsonist a match.
What a fool believes, he sees, no wise man has the power to reason away.
I think everybody agrees is that the first thing to do is to notify the vendor. Next, work on a fix has to be started. The question is, what comes after that?
Should users be notified ASAP, so that they are aware of the issue? There is something to be said for this. After all, if I found a vulnerability, somebody else may have found it, too. The sooner users know of the risk, the sooner they can take steps to reduce it. On the other hand, once you notify users, you can be sure the black hats know of the vulnerability and will try to exploit it. Had you not notified the users, they might have been safer.
Also, what if the vendor doesn't act responsibly? If they aren't working on a fix, or not doing it quickly enough, do you publicly disclose the vulnerability to coerce them into making haste? It may be a good idea, because the black hats may already be developing or even using exploits. On the other hand, you can be sure they will be once you disclose. Without knowing if the black hats already know of the vulnerability, or how the vendor will respond to the disclosure, it's hard to say.
Please correct me if I got my facts wrong.
I think we (meaning current and future users) need more information. More information on what sorts of vulnerabilities are most commonly exploited, and the consequences of these exploits. Information about what sort of vulnerabilities are most commonly found. Information about what we, independently from the vendors, can do to protect ourselves. And, importantly, about the security track record of vendors: which vendors get the most and severest vulnerabilities reported against them, and how do they deal with such reports?
Especially the last part is important, because it allows users to make choices based on what sort of security can be expected. This will make security something to compete on, which will lead to more secure choices being available.
Unfortunately, this sort of information will always paint a distorted picture: what if, for example, there are many more people looking for issues in MSIE than in Firefox? Firefox might seem more secure, while actually MSIE is the more secure of the two! Or what if Microsoft hires some brilliant minds to find holes in Ubuntu, whereas the people examining Windows have a hard time because (1) they don't have source code, (2) they don't have as much expertise, and (3) they have other things to do?
Please correct me if I got my facts wrong.
On the other hand, if a security update is only days away, full disclosure of the vulnerability won't get a fix in the next update. It takes time to write and test that a fix doesn't introduce new bugs. Additionally, what if the black hats haven't found the vulnerability yet? By announcing the vulnerability immediately after discovery, you haven't helped get the fix out sooner, and worse, you've made it more likely for an exploit to be developed.
Announcing a vulnerability immediately doesn't seem responsible, because it could likely do only harm. Why not give the vendor until the next security update, or until the security update after that if the next update is scheduled within two weeks, to write, test, and deploy the fix?
What a fool believes, he sees, no wise man has the power to reason away.
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.
Are you sure you'd want to install anything that comes out of Microsoft with all of 5 days of coding, testing, QA, regression testing, validation, etc?
I know I wouldn't. Give em 30 days at least.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
If there is really a fire, or a likelihood of a fire, you should inform the management so they can make an announcement that doesn't set off panic, which could lead to people being trampled to death.
Do that, and everyone in the theater is likely to die.
By the time you get to management and inform them (and, in many cases, convince them there really is a fire), and they can get to their PA system, the fire will probably have spread throughout the entire theater. In case of a fire, time is extremely important.
Same goes for exploit disclosure. If an exploit is found, it might be okay to keep it quiet for a little while, as there is a high probability of a fire rather than an actual fire. But the longer you wait, the more likely somebody else a little less honorable will also find the exploit.
If my operating system is vulnerable, I have a right to know it. I have paid for the OS in good faith (at least, if I use MS-Windows or Sun Solaris or Mac OSX). Like a recall on bad tires, I have the right to know my purchase is defective, and the manufacturer has a responsibility to let me know, and offer to fix it.
They *do not* have the right to allow me to remain ignorant of the flaws in their system. Period.
Microsoft is to software what Budweiser is to beer.
Wow, what could be a more compelling headline than one containing the words "16 Opinions"? Now that I think about it, the full excitement that awaits the reader isn't fully expressed unless it's "16 Opinions!!!".
Snoooooooore.
But if the bad guys haven't found the problem at this point, they surely will after this kind of announcement. Moreover, changing running production software can be very difficult. In this age of huge software systems composed of many pieces, you may not even know which components are running under the hood. For example, the recent OpenSSL security advisory -- can you name all the executables in your network that run OpenSSL? Can you upgrade them all? Have you?
They've got quotes from the others, but what about the customers *of* the vendors?
Two weeks ok, fine, take your time and test it, cause maybe no-one is being broken into right now. Four months? No-one should be exposed for that long. It's guarenteed to be found and exploited. And what if we know people are exploiting this vulnerability right now? Does that change our response? It should. There should be a hot fix or at least an advisory to disable the service (or the relevant portions) put out immediately. And how about releasing a signature all those people running intrusion detection systems or protocol level firewalls? Shouldn't that be done immediately in any case?
How we know is more important than what we know.
There's the opposite side of that story, you know.
You happen upon an easy vulnerability. A blackhat finds it in a month. You stay quiet for 4 months. Patch comes after a full year from when you find it. A single blackhat has used it for a year.
You happen upon an easy vulnerability. You announce it to the public. Every half-assed blackhat in the world finds it and uses it for a full year before the patch comes out.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
Are you trying to suggest that we shouldn't provide the right information for people who effectively manage their risk because some people are incapable of doing so? If an independant security analyst can find a vulnerability with no special tools or knowledge, then it is equally likely that a blackhat has found it. In fact, it's a lot more likely, as we suspect their are a hell of a lot more "bad guys" than there are "good guys".
How we know is more important than what we know.
"what if, for example, there are many more people looking for issues in MSIE than in Firefox?"
.. MSIE is more secure because people don't have access to the source and less people are looking for 'issues' in Firefox. Even if the above were true it defies logic that a browser is more/less secure because of the number of people examining it. And how do you explain the high number of bugs found in MSIE if they don't have access to the source code.
"Firefox might seem more secure, while actually MSIE is the more secure of the two!"
"Or what if Microsoft hires some brilliant minds to find holes in Ubuntu"
"whereas the people examining Windows have a hard time because (1) they don't have source code"
IF I can rephrase that
My opinion is that Firefox is more secure because unlike MSIE, it isn't welded to the OS. Firefox running as standard user under Linux is even more secure. A bug in Firefox usually leads to the users home dir being compromised. A bug in MSIE leads to the whole computer being compromised.
was Re:We Need More Information
davecb5620@gmail.com
that is if you read TFA of course. The average response is (except from IBM and Microsoft): oh, tell us, here is the e-mailaddress, we will do this, this and that, make a patch and then disclose the information. IBM is like: oh, tell us, we put it in the database and try finding a resolution. MIcrosoft says: Tell us, euhm... yeah, that's it, don't go tell anyone else, just us.
I mean, at least describe what an average process looks like and possible timeframes etc.
Custom electronics and digital signage for your business: www.evcircuits.com
The bad guys might know too????????? So????? Maybe the bad guys know stuff I don't....
Unless there is a secondary reason to disclose 120 for a patch to a complicated product is not that bad...... (Sure OSS will do it much quicker, that's why there is no propriatery software left these days.....)
Obviously your experience in teh field is limited to "I'm a geek so I know these things!!!!!!!!!!!!!!!!!"......
Get some real life experience where you have to make real life decisions, that have real life consequences (yeah yeah you'l claim years of experience at company, sure I do not buy it)...
Then go back and post again.....
Talk to you in 15 years dude...
If you announce it to the public and it still takes a year to patch then those people who are using the product in question should not be using that product. From a security point of view they are a lost cause. That said, it really depends how you announce it. If you say "I have found a serious vulnerability in product X, I recommend people don't use it until a patch for this issue has been released" then you have in no way reduced the time it will take a blackhat to find the vulnerability and produce an exploit for it.. and even when he does, he is unlikely to hand out the exploit as it will reduce the amount of time he has to utilize the exploit (as widespread use will put pressure on the vendor to release a patch faster, as customers flee from their product). Obviously if you say "I have found a serious vulnerability in product X, at this file:line or at this address in the binary" that will shorten the time that it takes a blackhat to find the vulnerability and it will also encourage more blackhats to look, and as such weaken their resolve not to distribute the exploit, so don't do that. Similarly, don't give out exploit tools yourself, even if they just "demonstrate" that there is a vulnerability and need to be modified to be used as hacking tools.
But doing nothing is worse and contacting only the vendor, who will take 120 days to release a patch, just as bad.
How we know is more important than what we know.
Blunt and honest. "Responsible disclosure" sounds like a new buzzword to suggest that full disclosure is irresponsible. It isn't. The only reasonable and sensible way to inform about a bug is by providing all information necessary to
see it
identify it
reproduce it
fix it
Yes, I may not be able to fix a bug in Windows. But with full disclosure I can reproduce it and find a stopgag that provides a temp fix 'til MS comes out of their rears.
If you only provide limited information, I cannot test my workaround against a valid test set, thus leaving me vulnerable.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
I agree four months seems like an excessively long time to stay quiet about a vulnerability, especially a serious one. Serious vulnerabilities should be fixed in the next security patch, unless the next one is too close for adequate testing.
In the case of a vulnerability that is being exploited, I agree that immediate action is necessary. However, with full disclosure there's always the possibility the some, or even most, black hats don't know about the vulnerability. In that case, again you've just made exploits more likely.
Doesn't it seem more responsible to disclose only what's necessary, such as that a hot fix is available for a security problem, or that disabling a certain service on a certain OS will prevent your system being exploited? That's responsible disclosure, which seems more responsible that full disclosure to me.
What a fool believes, he sees, no wise man has the power to reason away.
Yes, absolutely. But that's not the definition of "responsible disclosure" that the vendor would advocate. Because even the hint of a vulnerability without a patch available is bad for business.
How we know is more important than what we know.
If you found a security vulnerability in Windows, why would you trust Microsoft?
In your example, Microsoft has a $10,000 incentive to NEVER release a patch or give you credit for discovering it.
Will MS claim that the vulnerability was discovered in-house DAYS before you told them of it? What happens if you tell MS about the vulnerability and another researcher publishes the vulnerability while you have been patiently waiting several months for a patch and your check? If you tell MS about the vulnerability and another researcher had already told MS of the vulnerability, does MS tell you that it has already been reported, or do you wait for your check after the patch has been released? If MS tells you that it had already been reported, how do you know that is true? What if MS tells you that they don't consider it to be a vulnerability and then silently fixes it?
What a fool believes, he sees, no wise man has the power to reason away.
Amen Amen, On top of that, just think of all the poor free software developers who can't sit on the information for 120 days and have to fix it ASAP, because the only way to disclose the bug is to post to a ::gasp:: public mailing list!
Yes it sucks that people don't patch their systems, yes it is terrible that people can use publically disclosed information to attack systems, but this increased level of secrecy only gives you the illusion of security.
I'm probably not the only person on /. who has had severs hacked with an exploit during the grace period of some low level exploit, and as long as people believe this nonsense about grace periods, more people will be in the same boat with me.
At least with full disclosure there is a clear and immediate danger, where every individual has equal opportunity to mitigate the problem, shutting off unnecessary services, migrating to alternatives, etc. And of course that is why vendors hate the idea, you might switch vendors!
Exactly. Though there is no clearcut answer to this behalf.
It depends largely on the character of the exploit, I'd suggest. If you can stop it at the parameter firewall, at a non-standard port, tell the sysadmins to close that bloody port for security reasons.
If it can DoS your DNS by sending a specially crafted request, I'd suggest to leave it unpublished for a reasonable time. Not to invite the kids to find out what it is and DoS half of the DNSes for contempt.
Somehow it seems to boil down to the question if the user can actually do something reasonable about it (other than closing down the boxen), or not.
If there was a vulnerability in Apache self (not in some module), I'd personally prefer no immediate disclosure. Reasonably, almost nobody will simply be able to 'httpd stop' for several days, until the patch is available, tested and proven.
Clearly, a highly skilled blackhat could have found the same vulnerability as you. But the moment you go public, a highly skilled blackhat will have 'found' the same vulnerability as you.
Sure, it could take a while for the vulnerability to be fixed. But shouting publicly about it isn't necessarily going to get it fixed any quicker. That is the nature of software development - some fixes are non-trivial and need extensive engineering and testing. And if you honestly believe that companies can stop using vulnerable software then you know jack about the way the World works. Name me a database without any vulnerabilities, and I'll gladly laugh at you. Want to see how well the World gets on without databases?
I think that you misunderstood though. The vulnerability isn't disclosed loudly and publicly, but is disclosed to customers willing to pay for it. You might want to read that FSISAC (www.fsisac.com) uses critical alerts from iDefense to inform its customers (the banks that look after your hard earned cash) about critical vulnerabilities. So your bank has a chance to mitigate critical vulnerabilities before the black hats are told of their existence and start trying to hack your account details. I wouldn't like to speculate who else may be an iDefense customer, but I bet they've got budgets.
You might also want to note the disclosure policy at the bottom of http://www.idefense.com/legal.php. If the vendor is non-responsive then iDefense will go public with an advisory.
As to your IDS conundrum...
Inform the vendor of the daemon and hope that they fix it. Inform iDefense, get paid, and know that every attempt will be made to get the vendor to fix it whilst organisations that most need to know about it are informed. Go public and tell the black hats too.
Your choice.
One more data point of note - Even after a vendor releases a fix, systems don't patch themselves. Black hats have been exploiting this fact of life. The recent Microsoft MS06-040 vulnerability saw more trojans released immediately after the fix was made available than before. That tells me that black hats really do respond to public disclosure.
Responsible Disclosure: I work for VeriSign. My opinions are my own and not those of VeriSign.
Wouldn't knowing about a security exploit and failing to mitigate any damage that may result by failing to disclose to your customers this information make a company liable for any damages done to the customer's systems during the "grace period"?
I mean if I buy something, say a car, and the manufacturer knows about the defect, I can sue them for any damages that may occur as a result of their design flaw. Companies perform recalls because the cost of such suits exceeds the cost of replacing the goods in question. Additionally, if there is a flaw which they know about that results in death or injury, thay may also be found criminally negligent.
Can you sue Microsoft or Oracle for damages if someone exploits a bug they knew about, but didn't tell you about? And what protection could a EULA be for a company if they are found criminally negligent? You don't wave your rights not to be killed or injured or have your house not burnt down buy clicking the EULA.
I read that paragraph as saying that no public disclosure of the issue before disclosing to the vendor is acceptable, no matter how vague.
How we know is more important than what we know.
Checkthis out: zerodayinitiative
It's actually better than the parent's proposal, because you're not directly dependant on the company you've exploited the software of.
Yeah, but I don't care about your server. If I needed to care about it then you'd be able to afford the information and people needed to keep it secure.
On the other hand, the servers I do care about belong to companies that can afford to pay for that information. And they get a jump start on the Black Hats.
If you just say 'I found a vulnerability in Product X' nobody will listen seriously. A few will say 'where', which you can't respond to under your own example. Even those few will then ignore you without any proof of the problem.
If you say 'I found a vulnerability in Product X when you do Y', even without any details, the blackhats already know where to look and the kind of things to look for. For example, if you tell me that a program has a vulnerability related to images, I'm immediately going to think about the different types of buffer overflows in images. There are quite a few, but you have narrowed the search from the entire app to just the portions that deal directly with images.
This is what happened with the Apple wireless stuff recently. We were told 'it has to do with wireless, and you have to have it set to accept any connection available.' Oh man, that's almost POINTING at the problem. Unsurprisingly, black hats figured it out in time for their conference a couple weeks later and did a presentation on it.
And yes, it goes without saying that if you don't tell the vendor, you've done wrong.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
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.
I don't think a hard and fast 120 days rule makes sense, but I think a researcher should look at the characteristics of the vulnerability before deciding what is responsible, as well as the motivational effect on the software vendor. Is the vulnerability likely to have been discovered by blackhats? Is the vulnerability something that can be mitigated with firewalls, ACLs, or by disabling non-essential services if people know about it. Are their realistic alternatives people can employ to avoid this vulnerability (download Firefox). Will announcing the vulnerability make it obvious to blackhats or is it hard to find even if you are looking? Will announcing the vulnerability motivate the vendor to patch it more quickly?
There is a lot to consider for any individual case.
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 different than discovering a vulnerability. You've discovered an in-the-wild exploit. It tips the balance strongly towards full disclosure. If there is only one vendor for that type of product, and no work around, and the product is critical to those using it, it might be reasonable to just inform the vendor if you think they will fix it as fast as possible. Otherwise, full disclosure will almost always be the best option.
I think what you allude to is simply that there is no one rule for what you should always do. There are a lot of factors and each researchers has to evaluate them and make a call based upon them. So long as they are trying to be responsible and do the right thing, instead of grandstanding or trying to milk it for cash, I think we will all be pretty forgiving if they turn out to be in error.
Perhaps, then, the most responsible thing to do is to provide a proof of concept to the software company to prove that your bug is serious, and then post publically "I have found a bug in foobar. By restricting network access to the whammy service to trusted systems, you can mitigate the risk of attack. A proof of concept has been provided to the company but will not be made available to the public."
If I have been able to see further than others, it is because I bought a pair of binoculars.
i'm for full disclosure. ... tz-tz-tz.
the reason is simple. for at least 50%
of software flaws there's a workaround.
if admins get full disclosure, they can shut-down
the faulty piece of code or filter it, or work around
it whatnot.
but just reporting it back to the vendor and then
sitting back, knowing that there are >250'000 computers
"out-there" with a glaring hole
full disclosure also "forces" vendors to check their
code better before releasing it to the public.
vendors should be held resonsible for flaws.
also $$$ wise.
"hey tom! did you see that red explorer that just overtook
us?"
"yep, defenetly speeding."
"i know for a fact that that model got bad brakes."
"..."
Meh. If people ignore your vague warning and then get burned, they'll listen to you next time. If they don't get burned then no problem.
How we know is more important than what we know.
Sounds responsible to me.
How we know is more important than what we know.
You ASSume that the problem is not being solved in a reasonable timeframe, and that public disclosure will accelerate the fix. What if that isn't the case. There are many exploits that are known to the real blackhats, that they keep to themselves and don't share. If a security researcher discovers one of these (he may even know that it is in the wild) should he immediately tell the world? Then a vulnerability that was once only exploited by a small group is know exploitable by ever 1337 cr4ck3r and script kiddie in the world.
Even if the vendor takes 4 months to patch the vulnerability when you think it should take 4 weeks, do you make the public more or less safe by your disclosure?
Si vis pacem, para bellum
The only thing more annoying than a Libertarian is an (un|mis)informed Libertarian
If my name was RMS or Linus, I could expect that, yes. But in the world of IT, I'm nobody. Anyone who heeds just anyone who screams is crazy. You have to have a way to filter out the liars, cheats, scammers, etc. And lack of proof is pretty compelling.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
Good morning, Mr. Deadhorse. I'm here to beat you.
well, obviously you have to build a reputation for yourself, but if you never proclaim anything then no-one will ever believe any of your warnings.
How we know is more important than what we know.
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).
and after careful consideration of the issues, I have concluded that the appropriate amount of time to wait before going public is 10.853 days.
Test 1 2 3 4
Unless the vulnerability you have discovered was JUST introduced in a patch or update, the vulnerability has been sitting there undiscovered for some unknown period of time (depending on the system, it could have been there for years).
You found a bug in Sendmail. You contact Eric Allman, you ask him how long it will take him to get his downstreams to push fixes through the distribution channels, and you agree to withold the sploit until he says everybody's ready, and he gives you credit for finding the problems and publically thanks you for your co-operation and for helping make the internet a better place.
You found a bug in a CA product. You use a library computer and an anonymous remailer to hit every CA address that seems remotely applicable, telling them the details of the spoit, and that you will release in two weeks. Two weeks later, you full disclose (again as anonymously as possible) so that CA's customers will know they need to patch (after all, CA is unlikely to aggressively publicize their mistake).
Why the difference? Sendmail Inc. and Eric Allman have proved that they won't victimize or prosecute people who help them secure their code, and that they will do everything possible to minimize damage while providing full credit to security researchers. Many open-source projects can be counted on to act this way (I'm sure others will post examples) despite operating on tiny or non-existent budgets. In contrast, most gigantic zaibatsus with enormous programming resources simply will not fix bugs if given any other choice - and discrediting or victimizing you might seem like a viable choice to some corporate pinhead who really doesn't care about anything but profits for the quarter.
You might vary that "two weeks" figure based on how big a vendor's programming staff is, or how complex the problem is, or how serious the vendor is in regards to security, but in general you need to set a hard deadline and stick to it. It's the responsible thing to do.
I'd read this article when it first came out and responded with a blog posting, discussing the top 10 failures of responsible disclosure.
There's an entire full disclosure debate bibliography.
I read the article last week with great interest, having previous worked for iDefense.
I've posted my thoughts on the top ten failures of 'responsible disclosure' to my blog.
Michael Sutton
Security Evangelist
SPI Dynamics
Without knowing more about the quality of those fixes, your statistics are worse than meaningless; they are potentially misleading.
Si vis pacem, para bellum
The only thing more annoying than a Libertarian is an (un|mis)informed Libertarian
The compromise that makes the most sense to me is RFPolicy. Put simply, this provides a 5-day contact period, and requires the vendor to keep the reporter notified of the status of the fix. Time to actual disclosure is then based on how cooperative the vendor is being. This (in theory) ensures a fix in a reasonable time frame, from the point of view of the reporter, while suggesting that the disclosure of the vulnerability should be held back as appropriate in order to do a proper fix, and giving good timelines should the vendor not be responsive or cooperative.