What is "responsible disclosure"?
Jarrod Loidl
Back in 2009 I wrote a blog post about vulnerability disclosure. It's interesting reading the post four years later, looking at things that have happened at places I've worked, vulnerabilities I've reported personally or watched others submit.
At the core of it, my thinking still pretty much remains the same but I'm going to put some things out there I've learned over time. There's not a lot of information out there for security professionals on how to report vulnerabilities. I'm no Charlie Miller or David Lichfield but four years later I am a little older and wiser and can share some of my own experiences on this.
I think that, regardless of the side of the disclosure debate you sit on, you should agree with what I’m about to write.
This whole responsible disclosure thing is predicated on a series of assumptions (and is even asked point blank in some cases). They typically will go something like this:
• The researcher assumers that the vendor is willing to receive and acknowledge the vulnerabilities exist.
• The researcher assumes that the vendor will fix the vulnerabilities in a reasonable timeframe.
• The researcher assumes that the vendor will give credit for their good work.
• The researcher assumes that the vendor will not try to mothball them, threaten them, sue them or gag them.
Now we all know what they say about assumptions.
A few things I’ll suggest below might be deemed counter-productive, controversial or perhaps even wrong, but I say them to help security professionals. I think that is more important than towing any party line.
If you research vulnerabilities, work in the disclosure process, or write advisories, you should probably read this very carefully. Especially if you are about to write your first advisory.
1) If you aren't in a position to influence over a vendor then disclosing to the vendor directly is probably a bad idea.
You need something to leverage the advisory. You need a method to compel them to fix it or at the very least, persuade them that fixing it is in their best interests— over and above their obligations to provide a secure product.
This could mean the threat of public disclosure—sure. That is obvious. But what if your client doesn't want to go that route, then what? Can you drop the vendor? Can you make it clear you will not renew or extend support agreements and create a tender to look for a response? Tenders are actually good ways to force the vendor and the client organisation who owns the product to examine how much they value the relationship. This is doubly ideal if your current contractual arrangements are inadequate. Can you go through a third party? A CERT? A broker like iDefense perhaps?
Lesson: Figure out how you are going to compel a vendor response before you give them anything.
2) Not all vendors are equal.
I wrote my first 'formal' advisory last year. (I had been involved in several disclosures before but this was my first 'proper' one). When it was written I had a pre-existing relationship with the vendor, I knew the people coming into receipt of that advisory and foreknowledge of how it would be handled. That gave me a lot of confidence it would be dealt with appropriately.
That same year, however, I'd seen one vendor who’d threatened legal action when they received an advisory. Now, if you are a vendor and you come into receipt of an advisory, and you threaten to sue the person providing it when they happen to be a strategic partner—and a client of yours—you’re doing it wrong. Really, wrong.
If you want to disclose directly to a vendor pay close attention to the company and check out their history. It really doesn't take long and in some cases, you know the answer. How good are they with responding to advisories? What is their turn-around time on fixing vulnerabilities? If they have a history of threatening folks with legal action, perhaps it is not in your best interest to disclose to them directly. Can you use a third party? Should you go public? There are plenty of folks who go down the public disclosure route because it's easier than going to a vendor directly. Does Oracle make Brian Krebs go through their online portal to report vulnerabilities when he reports a new Java 0 day is on the market in an exploit pack?
Lesson: Know your vendor's history with security vulnerabilities before you decide to report it to them directly.
Lesson: Figure our your advisory method.
3) Be prepared to change your approach
Unless you are a vulnerability researcher-gloryhound or someone who, on principle, drops everything publicly then you will find times where a single approach isn't going to work. Today you might disclose to a vendor because your client has a strategic relationship with them. Tomorrow you might go public because the vendor sucks or you believe the greater public interest is served by making the information public to allow everyone to determine their own response. The time after that you may work with an intermediary on the disclosure.
Dan Kaminsky worked the various CERTs on his famous DNS flaw years ago because the problem was so widespread. How much he can be credited for that co-ordination piece is certainly up for debate but we can all agree that the problem was widespread and merited a co-ordinated response. At the end of the day, there is no "one size fits all" approach. But in being flexible, I think the key advice I want to impart here is to look out for yourself first and foremost. Not the vendor. Not the client, but yourself –the disclosing party. Why? Because you enter murky waters when you disclose vulnerabilities.
Do you own the vulnerability? If not who does? Do you have the right to disclose? If so under what conditions? If you did it for a client, do they own the work (under intellectual property laws they typically do, unless your contract states otherwise). Does your employer’s work policies and practices cover you in the disclosure? Are their lawyers across it? And are they willing to support you as part of the disclosure? If you are not comfortable as the reporting party with any of this then do NOT disclose. If you don't believe the vendor will act in an ethical fashion or you don't believe your client and/or employer will support you, then don't do it. It just isn't worth it. Disclosures take time, they can be stressful and the last thing you need is a lack of support on the home front.
Lesson: Cover your butt. Hope for the best but plan for the worst.
Lesson: If in doubt, do not disclose.
I look forward to any opinions or posts of reply to this! Especially people with a long history of vulnerability research and disclosure - that goes double if you sell them or refuse to disclose at all! I would love to know your thoughts and reasons. We all are in this field together and sharing experiences will help those entering the field and shape people's thought on how to manage vulnerabilities this in future.