Taking Responsible Disclosure for Granted
The last couple years of my career have been interesting when it comes to disclosing vulnerabilities. I have worked on some pretty big ones and a few aren’t even public yet. Based on this I have been thinking a lot about how the industry as a whole handles vulnerability disclosure. Yes, I am aware that this debate has raged on for years and will probably never be settled but I thought I would share my random thoughts here.
I have always been a fan of responsible disclosure. Wait, let me first define what I feel responsible disclosure is. To me it is very simple, do your best to get the vendor to fix the vulnerability without increasing the risk for the general Internet ecosystem.
Of course one could easily argue that the existence of the bug is already a huge risk and therefore should be disclosed immediately to the world. While there is some truth in that statement my personal issue with going that route is that disclosing something without a patch or at least with some very strong mitigation options does not help anyone increase their security and simply shines a spotlight on the flaw.
Over my career I have been involved with some pretty cool and pretty serious vulnerabilities. My involvement has mostly been around reporting the issue to the vendor and working with them to fix the issue. Believe it or not this can be a lot of work depending on the vendor. In some cases you simply toss the crash dump over the fence and the vendor is able to run with it. In other cases you end up having to supply PoC, which I hate having to do BTW, and in even more extreme cases you actually have to sit down prove the vulnerability on a live system and even offer fix advice. I have even been involved in cases where a vendor has supplied a beta patch in which the scary smart people I work with quickly prove to also be flawed.
Unfortunately, over the years, the phrase “responsible disclosure” has become rather meaningless and really a one way street. Vendors, note I work for one, are very quick to remind researchers that they need to do the responsible thing and while most researchers do attempt to show as much good faith as they can. The vendors themselves seem to forget that responsibility and disclosure is a two-way street that requires both the vendor and the researcher to act in a manner that is best for those whom are vulnerable.
Some vendors do a pretty good job while others are still extremely horrible. Believe it 0r not, but this is a place where other vendors should look at the Microsoft MSRC model. The industry went from beating up on Microsoft during the 80s and 90s to seeing some great improvements in handling vulnerabilities and some proven process. The only real criticism I can toss towards the folks in Redmond is that they are still a bit slow on some issues and yes I am still pissed at Culp for calling researchers Terrorists after 9/11. 😉
I am really not sure where I am going with all of this but I am finding myself becoming more and more frustrated with various vendors and their ability to invoke “responsibility” of the bug finder while not acting responsible themselves. While I understand that this has become a business and fixing bugs cost money, the vendors need to understand that the researcher didn’t create the bug. Their bad development process and lack of anything resembling a SDL process did.
Based on this frustration I have some advice for vendors. Note that all of this is coming from the perspective of someone reporting a bug and not from the side of a vendor.
1.) The researcher is not your enemy. In fact, if you have a researcher contacting you about a vulnerability he/she found in your product, they are the exact opposite of the enemy. They just provided you wtih some free QA and are handing you a great opportunity to not only improve your product but be seen in the public eye as a company that actually cares about their customer’s security and reacts accordingly.
2.) If the bug is stupid or not exploitable. Call it out. But do so in a constructive manner. Spend the time to sit down with the researcher and make sure you fully understand what they are telling you and that they understand how you came to the conclusion you have. Again, you are not adversaries.
3.) Be honest about patch timelines and potential issues you may have. I don’t expect a vendor to share sensitive information with a researcher but being genuine about timelines and the process to produce a patch helps. Most will understand that you can’t produce a safe patch in 30 days or less. But a reasonable timeline should be offered,
4.) Over communicate. Nothing is worse when a researcher feels like they are being ignored or nothing is going on with the bug they reported. As they sit and look for some sort of communication back from the vendor their mouse also hovers over the send key of a full-disclosure post. Vendors are one forgotten status update away from having the issue dropped on them.
5.) Lawyers won’t work – usually. Enough companies have tried and failed to silence a researcher with lawyers. If you contact your legal team BEFORE you contact your developers with a vulnerability report expect to have the vulnerability leak to the public. Again, the researcher is not the enemy. Your bad coding process is.
6.) Give the researcher credit. At the very least you should credit the researcher. Remember, unless they have sold this bug to one of the clearinghouses, they have done this QA work for you FOR FREE. They should get recognition for their work. Hell if you have headcount and good workplace — hire this person to find more bugs for you. Researchers like money just as much as corporations.
7.) Applying pressure via other means such as mutual customers or corporate relationships will just build resentment. Any attempt to silence the researcher will simply turn a positive situation in to an adversarial one. As a vendor you do not want this.
8.) Stay honest and back up your promises. If you make commitments to the researcher. Follow them. It’s really that simple.
9.) Use the vulnerability report as a mechanism to improve your internal development and QA process.
10.) Do not use #9 as a way to stall a patch or prevent disclosure.
I know the above seems very simplistic and obvious to most of us but believe it or not the majority of vendors out there still do not get it. Vendors need to realize that having a bug found in your product is actually an opportunity and not a set back.
I encourage all researchers to remind vendors of THEIR responsiblity in the process. Be open with the vendor with what you feel a reasonable process to fix the vulnerability is. The more approachable you are, the easier the entire process will be.
Got a vendor thats not cooperating? Contact me and I can try and help.
Of course your other option is to simply disclose the issue to the public but that becomes a whole new can of worms. My next post, when I get around to it, will talk about the issues that a researcher faces when they go this route.