Slashdot Mirror
What is Responsible Disclosure for Security Flaws?
Silverdot writes "In an article on ZDNet, the author brought up a few cases of uneasy relationships between security researchers and software firms. While those who report the bugs should first seek to notify and work with the software firm to resolve the flaw, One researcher commented: "All researchers should follow responsible disclosure guidelines, but if a vendor like Microsoft takes six months to a year to fix a flaw, a researcher has every right to release the details." Should the onus be on the software firm to manage each issue and the relationship well, or does it fall to the morally responsible user?"
The cost of secrecy is high. Reasonable response times ( up to, say, 3 months) before disclosure should be allowed - even for firms that seem to be sitting on their hands, and if the firm is close to a patch and they are willing to communicate and work with the researcher a longer time may be reasonable. Overall, disclosure of a problem is always in the USERS best interest, and secrecy is always in the SOFTWARE FIRMS best interest. The longer a known security issue exists, in secret, the more likely it is that someone else has found it - and that puts everyone at risk. The rights of users ( who are victims of the software firms bad code) should always come before the rights of the software firm. Always. So this means disclosure should be seen as a blessing. Those who complain about irresponsible researchers putting everyone at risk are wrong - everyone is already AT RISK. Failure to let me know what risks I face should be seen as the problem. I need to know.
I have nothing to hide. So, why are you spying on me?
"Responsible disclosure" is a propganda term propogated by the software firms to a) get as much time as possible to fix security holes, and b) indemnify themselves as much as possible against any public disclosure of said security holes by labeling the disclosers as 'irresponsible'.
If a security hole exists, it exists, despite how much public discussion about said hole is quashed. Today more than ever, there are unscrupulous people out there laboring to find and take advantage of these holes. Muzzling the virtuous hackers, who only wish to make things more secure, is counterproductive in the extreme. The only 'responsible disclosure' is full and immediate disclosure.
____
~ |rip/\/\aster /\/\onkey
If you find a security hole in someone else's code you can either:
1) use the DJB approach: reveal the hole in a public forum, preferably with a working exploit.
2) use my preferred approach: fix your clients' copies of the program, and otherwise keep quiet. Consider it a competitive advantage when the next Apache/SSH/PHP worm hits.
Any other approach is an utter waste of time, for everyone except the vendor.
If you reveal the flaw only to the author, you are:
a) Working for someone else without getting paid.
b) Saying "it's okay" to write software with security holes, because shucks, some kind soul will fix it for you.
c) Not telling the rest of us, the sysadmins of the world, how to protect our own systems. You see, the company or author has already demonstrated incompetence. Why help them? Of course you don't owe anybody anything (see point #a) but if you're going to tell anybody, tell the people with the most to lose!
Of course, I'm assuming we're working with software where you have the source code. Secure software without source code is an oxymoron. And no, I don't think the license makes code more secure, since maybe 95% of the coders out there can't code properly. My ability to audit is what makes it more secure, and yes, I do as much of that as I can.
Let me make the point clear: I don't care if the author fixes the code or not, or how quickly he can "patch". I need to know the details of the problem so I can solve it myself. That's what's important.
People who advocate "irresponsible disclosure" (my term for any disclosure that doesn't inform the end-user first) are really secretly afraid that someone will someday find flaws in THEIR systems and embarrass them. But that's the point: embarrassment is a cost, and people will try to minimize costs any way they can. At some point they will actually try writing secure software. And maybe at some point, users will start demanding secure software.
I think we can all agree that the security situation is getting worse, not better. Most of the software I see these days is garbage, to put it mildly. Bloated, complex, insecure.
Constantly holding the hand of authors via irresponsible disclosure is not going to solve the problem. Do you want to wait until the government regulates software, basically punishing everybody for the sins of the incompetent? Or should we let market forces do their thing?
I mostly agree with your overall analysis, but I'm compelled to point out that this one statement seems self-contradicting. What is the difference whether a security issue is "known...in secret" rather than simply "unknown"? I submit that a better way to say this would be that "the longer any security issue exists, the more likely it is that someone else has found it," without regard to how known or unknown it may be during the interim.
The only way this is not true is if you consider the (perhaps non-trivial) cases where the "secret" is leaked, intentionally or otherwise.
Responsible disclosure from Microsoft's perspective: You tell us and only us. We'll tell the rest of the world when we think it's necessary (if ever).
The NSA: The only part of the US government that actually listens.
And what about users that would be able to do something against the security risk (not use a certain program, disable a vulerable service or firewall it in for example), if they only would be aware of it?
Common Sense is sometimes violated egregiously by one side or another, and then this is raised as an issue. If a security researcher sends one email to some ill-checked "bugs@" address and gets no response, then just releases a couple weeks later, that's irresponsible.
When someone emails a vendor many times at many addresses, finally gets a response where they tell him, "We're looking into it", and then proceeds to cease communicating for 45 days, that's irresponsible by the vendor, and the researcher has every right (and some would say, a responsibility) to publish.
Where's the middle ground? Well, it's a wide open space. Those without bad ulterior motives (ie, publicity-hungry or vendor-hating researchers, or head-in-sand or deny-first-ask-questions-later vendors) don't really have much difficulty negotiating the middle ground, because there's a lot of room. The problem, of course, is that the only time you *hear* about disclosure issues is when someone is being a muttonhead - either vendors trying to keep secrets, or researchers who feel no sense of responsibility or make the most token efforts to make contact. For the rest, there's little debate, because it's just easy to do it right.
Responsible disclosure has no real benefit to the end user. It may stop some percentage of big outbreaks of worms but it doesnt in any way make life for admins guarding sensetive information a bit easier. From what i have understood many exploits are used by crackers long before they are in the wild. That is, many networks and servers are broken into and gathered for intel long before there is a patch, sometimes even for years.
Responsible disclosure only lenghten the period for the crackers in wich they can use their exploits for real cracking. It gives at best a breather for software manufacturers to drag their ass. It also doesnt promote real testing and auditing of software before its shipped. I would as an end user much prefer more tested software, that includes OSS thank you very much. Current release cycles is way to short to give any time for testing.
HTTP/1.1 400
The justification seems to be that they might already know of the vulnerability. A weak argument if ever there was one. Just because some black hats know of it doesn't mean all of them do.
Good point. From now on, I'm only going to allow those blackhats that don't know of the vulnerability to access my services.
And there's no evidence that any of them know of the vulnerability before the flaw is revealed.
You have a narrow view of reality. How can you know that no one knows of something before it's officially revealed?
The risk that they might know of it is what drives it.
While I'm on the fence as to which I support ( full disclosure or informed disclosure ), your arguments are flawed, and I had to point that out.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
" The best security is to inform all users once a flaw is discovered."
No, it isn't.
The best security is for software vendors, security firms, and AV software providers to share information and work cooperatively to get AV updates to end users (average Joe Sixpack) while the OEM vendor works on a patch--and keep it out of the "public" eye.
Your internet-connected mom/gandmother/uncle/aunt would never know they were vulnerable anyway, even if the story was on the front page of every newspaper. Unless their machine is set up to automatically check for and install AV and security upgrades, the machine is proably already compromised. If it is so set up, they are covered.
Meanwhile, the script kiddies (as opposed to true criminal hackers) will never be the wiser until the AV updates and patches have already been out for quite a while, and therefore most if not all responsible users are protected.
Ignorance is curable, stupid is forever.
The answer is massive class-action lawsuit. Consider the following scenario. A manager at Microsoft badgers his employees in order to hustle an Internet software program out the door. The product is now flawed and open to attack by worms and viruses.
Now picture the one at fault to be Joe Blow working from his basement during his "free time" outside of the 65 hour work week at his real job. Class action lawsuits like this would kill open source completely.
Now, here's where the improved security occurs. The customers who bought the flawed product initiate a class-action lawsuit against Microsoft and win $10 billion from the company. Microsoft then fires the manager who forced his employees to hustle a product to completion. The manager of that manager is also fired.
Or Joe Blow is now in prison, is fined an amount he can never pay, his credit, business, and everything is ruined. End users who could have received a patch if it wasn't for that "damned lawsuit happy group being so pushy on time limits" are left with an end-of-life broken product. Don't be so hastey to criminalize the innocent. Too many laws and lawsuits these days do just that.
Just another perspective....
Two roads diverged in a wood, and I - I took the one the bus load of girls just went down.
I use OpenBSD too, so don't start with me.
How can you be happy when someone else is suffering? It's not your grandmothers fault she uses windows. OpenBSD is NOT appropriate for "home users", and it's not designed to be, and it cannot ever be as secure as it is yet as functional as required for non-power-users.
Every operating system in use on PC's has security issues, even openBSD. OpenBSD is where it is because it's entire focus is security/correctness.
Security and correctness are NOT the most important aspect of general software development - if they were the only requirements, then a lead box buried in the ground would easily be more secure than openBSD. The issue is functionality vs security and correctness.
When there is something that works as well as windows for what people that use windows need to do, but has fewer problems, people will change to it in droves. For some people, that is Mac OS - although it has its own severe security problems - do you laugh when people with macs have to reboot their machines because of SoftwareUpdates ?
In any case - 0 day full disclosure hurts the majority of computer users. No amount of pain will convince them to stop using windows. If you want people to stop using windows, develop a credible alternative. Don't sit and laugh at people that don't have better choices available to them, and then say things like "i support people making life harder for windows users".
My opinions are my own, and do not necessarily represent those of my employer.
Refuse to sign the NDA. Then make a public announcement: "$AGENCY has notified us that a possible vulnerability exists, however they won't tell us what the vulnerability is unless we sign an NDA. Comitting a patch to fix the problem to CVS or releasing fixed code before they allow it would violate the NDA, and we aren't willing to agree to deliberately not fix a security bug.". Let the resulting PR headache be $AGENCY's headache.