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 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
Oddly enough, I used to work on a project for a huge company where this happened. We had a large search-engine like project that was running much slower on a 16 proc Sun box than I thought it should. I noticed that 40% of our traffic came from the same 5 subdomains, representing over 10 - 20,000 hits/hour. "Who uses a search engine that much?" I asked.
Me: Something fishy is going on here.
Boss: Report your findings to the project team.
Project Team: Hmmm... that is fishy
[weeks go by]
Me: Something fishy is STILL going on here.
Boss: Report your findings to the project team.
Project Team: We don't have a disclaimer on our site that restricts the number of hits/hour. Contact legal.
Legal: We'll get back to you.
[weeks go by]
Me: Something fishy is STILL going on here, and it's getting worse!
Boss: Report your findings to the project team.
Project Team: Did legal get back to you?
Legal: We'll get back to you.
[weeks go by]
Me: Something fishy is STILL going on here, can I at least block them via hosts.allow or a firewall?
Boss: Report your findings to the project team.
Project Team: Hmmm... I don't know. Did legal get back to you?
Legal: We'll get back to you.
[weeks go by]
Slashdot: "Your search engine is a known hack to alter page rankings at Google!"
Slashdot Commenters: OH yeah, that's been a problem for a while. That damn company!
Me: YIKES!! SLASHDOT has posted our company name in connection with fraud. AGAIN!
Boss: FUCK! DO SOMETHING! This is a PR nightmare!
Project Team: FUCK! DO SOMETHING! This is a PR nightmare!
Me: Luckily, I have already written a script to do so. Give me a sec--
Legal: We have shut down all admin access to this box, because there was this article on Slashdot, and we need to see if it's been hacked. We've opened a ticket.
Me: GAAAAAHHH!!!
The Openswan project is directly affected by this this month. We were contacted by an agency and asked to sign a non-disclosure agreement, following which they would tell us of a possible vulnerability in our code. This non-disclosure would prevent us to release details of the vulnerability until such time as the rest of the "group" would be ready for it to be announced.
In the case of an Open Source product, we cannot even do a "stealth" fix; we have to describe what each patch does when we commit it to CVS. That would make the vulnerability public and would be a no-no to this agency.
In essence, the agency could decide which bug we could fix and which ones we could not.
I see this as the equivalent to blackmail: Sign our non-disclosure and we will give you a possible vulnerability; don't sign it and you will look bad when the vulnerability is made public.
I am a CISSP, and quite willing to hold on the patch until others can fix their code if the allowed time is reasonable, but the non-disclosure is broad and has no time limitations... So what the heck should we do ?
I have actually been in the middle of this before, having found a way to passively grab billing information from a larger online subscription-based game. A colleague and I built a complete technical description of the issues, theoretical "worst case" possibilities, as well as a working proof-of-concept exploit, making it clear that we would wait for a suitable fix to be in place before we would release details. We got an email back within several hours from one of the lead programmers who wanted to do a conference call but when we agreed, we never heard from him again.
We were then contacted by a manager-type that this 2-year-old hole was already being fixed. We offered our expertise to review their solution but they weren't interested. Instead, 2 special agents from the FBI showed up at my work to interrogate my involvement in felony extortion.
After a 4 hour long interview session (during which I was escorted to the restroom and watercooler by an armed agent) and I provided all correspondance and source code, they left and never came back. The best part the WTF? look I got when I described how this company was transmitting credit card information XORed with a cleartext seed transmitted in the previous packet. Second place had to be the "Why are we wasting our time here?" look I got when I explained the only credit card information I have actually seen was my own.
The hole was silently fixed in a patch distributed weeks later, and replaced with another algorithm which was also easily exploited. Again, we went through the entire process of creating documentation and a working exploit and sending it to the company. This hole was patched months later.
The company's response was always hostile at best, which I found odd considering we were trying to help them protect their customers. They never disclosed (publicly or to the credit corporations providing merchant accounts) that there was any issue.
American Express has an extremely specific policy on security, and have a minumum requirements policy which all online merchants are supposed to adhere to. They also require you to notify them if security has been compromised. California law also states that card holders must be notified if their account information may have been compromised. Apparently it's not a big deal if noone abides by these rules.
When the company is unresponsive in resolving security flaws, I feel that disclosure is imperative to allow users to take their own precautions to protect themselves. I'm not malicious, but I imagine that there are a lot of people smarter than I am that are.