Slashdot Mirror
Why Responsible Vulnerability Disclosure Is Painful and Inefficient
A recent rant up at Attrition.org highlights problems with the responsible disclosure of security issues. While some vendors are happy to do their own research and patch reported problems, others drag their feet and make unreasonable demands on a researcher's time and effort, making anonymous public disclosure an ever-more-tempting option. Quoting:
"After a couple hours of poking, I found a huge unauthenticated confidentiality hole. Once the euphoria wore off, I realized I had a big problem on my hands. I had to tell my employer's app owners and we had to assess risk and make a decision on what to do about it. After some quick meetings with stakeholders, we decided to severely limit access to the thing while we worked with the vendor. The vendor refused to acknowledge it was a security issue. Odd, considering most everyone who sees the issue unmistakably agrees that it is not acceptable. Now I'm forced to play hardball, yet nobody wants to fully-disclose and destroy relations with this vendor, whose software is somewhat relied on. Meanwhile, I know there are hundreds of institutions, small and large, using this software who have no idea that it has flawed security and who would probably not find the risk acceptable. What can I do? Nothing. Oh well, sucks to be them. ... I've had a vendor tell me to put a webapp firewall in front of their software. Did they offer to pay for it? No. That would be like Toyota telling its customers to buy ejector seats (unsubsidized ejector seats, that is) to resolve the accelerator problem in their vehicles. I've had other vendors demand I spend time helping them understand the issue, basically consulting for free for them. Have you ever knocked on a neighbor's door to tell them they left their headlights on? Did they then require you to cook them dinner? Exactly..."
that there is an exploit that allows a user to bump their post up to first.
Interesting, but...
You're then basically telling anyone who might employ such an exploit how to compromise your system.
My responsibility is to protect my system first, and then to help other people protect their systems.
I'm not saying that a leak of an exploit isn't good, I'm saying you need to make sure that something is protecting your system from that exploit before you leak it.
The shareholder meeting. Simply note that you reported bug # XXXX some months ago, and it has not been acted on. You wouldn't mention it except that it's a security vulnerability that, if disclosed, would tank the share price for the company. So in that light, when will this vulnerability be addressed? Let everyone else take it from there.
-- Two men say they're Jesus. One of them must be wrong. - Dire Straits
Exactly.
And this is the right way to go about it.
And the nice thing is that when you report it in the filing, the other company will be shamed because other people will figure out who it is, yet you are not really adding to your own risk, because in the SEC filing you use some words like have been used in this article:
"We have discovered a security vulnerability in a third party web application platform we use. If this is successfully exploited, (list of bad things that could happen). We have informed the vendor, and they have so far been unresponsive in fixing it. We are working diligently to deploy a firewall in front of the applications, but there is no guarantee that this vulnerability will not be exploited before we have that fully deployed, or the vendor gives us a fix."
This is exactly the chain of command/control you want to use. You tell your counterparts at the other company that your company's policy requires you to report it to the lawyer, the lawyer tells his counterpart that SEC rules require him to disclose the vulnerability, and then he does it in the next report. End of story.
Then the ball is in the other company's court to either fix the vulnerability or prove to your satisfaction that it isn't a problem.
Send the vendor an email:
Thank you for clarifying that this is not a security issue. I can now safely post information about this non-security issue into public websites and ask for workarounds from helpful hackers. This would not be possible for security related bugs as those are best be kept secret for a few weeks, so that the vendor can provide and distribute a fix for it.