Taking Responsible Disclosure for Granted – Part Duh
In a previous post I talked about responsible disclosure and how I feel Vendors who are receiving vulnerability reports should be acting. Unfortunately, even today vendors who act in a responsible manner are in the minority. As promised in that post, this is the follow-up.
Over the years and over different jobs at various places I have been very lucky to work with some very smart researchers. I will resist the urge to name drop them all here but I will say that all of them are much smarter than I am and I have manged to learn as much as I can from each of them — even though I have probably killed all those brain cells in recent years and forgotten everything. 😉
One thing I have noticed, and hopefully this doesn’t come across as an insult, is that finding a researcher who is both very good at finding bugs but also able to deal with the “business” side of disclosing that bug is a rare find. Don’t get me wrong, there are a few out there that I can think of, but more often than not the disconnect between the technical brilliance and the ability to deal with the, for lack of a better word, politics around disclosure is typically a big one.
This alone makes dealing with vulnerability information a huge challenge for most on both sides of the coin. You end up with a highly technical person talking to a less technical business focused person and frustration builds quickly on both sides. Of course when a bug is mishandled you end up with even a bigger problem to deal with.
As I did in my last post I wanted to share some advice based on my experience of what a researcher can expect. Hopefully this will help shed some light on just what goes through a vendors mind when you send them that bug report.
Before I get in to that however, let me state this. When you find a vulnerability it is YOURS. You own it. The vendor who wrote the software or created the hardware that you have poked holes in does not own your work. You are free to do what you want with it, sell it, drop it on the internet for free, or use it to impress girls (has that ever worked?).
Obviously, if you have followed my blog or if you know me you know that I support reporting the issue to the vendor and working with them to get it fixed. But in all honesty, you can ignore everything I say and do what you want. 🙂
As I am writing this, I realized that the entire notion of asking someone who just found a bug in your product to act responsibly is a bit hypocritical, I mean, if you had tested your product properly would the bug not exist in the first place? So who is really responsible? That said, here is my advice for researchers:
1.) If you are not willing to put up with various annoyances including but not limited to stupidity, denial and perceived laziness do not bother reporting your bug to the vendor. Go and sell it to one of the various companies that purchases vulnerabilities and move on with your life.
2.) While what you have done is probably very cool remember – THE VENDOR IS SCARED OF YOU. Upon first contact they have no idea what your true intentions are and they are in immediate fire drill mode. Try to be as straight forward and honest with the vendor as possible. Do not go in with a hidden agenda, it never works.
3.) Most vendors will put their foots in their mouths. Remember, the vendor is now scrambling and you are typically talking to someone who really does not understand what you are telling him and that person is now trying to relay your message to the developers who are probably replying with “thats impossible”. A bit of patience can go a long way. But obviously, only so much, if the vendor never gets out of the denial stage, they have bigger problems than your bug.
4.) When you approach a vendor asking for money or for a business relationship in exchange for the vulnerability you will always, despite your true intentions, appear shady and potentially get yourself in a lot of trouble. If you want to make money off of your find, sell it to a third-party.
5.) Most vendors will not sue you or use other legal means to keep the bug quiet. That said, it never hurts to seek legal advice. I highly recommend the smart folks over at the EFF.
6.) Demanding a Non-Disclosure agreement will be typically met with resistence. This is not because the vendor wants to play games but because the amount of effort required to have legal review and approve a NDA for this type of thing far outweighs the benefit of having one. In addition, as a researcher you should avoid signing a contract of any type with the vendor. Remember it is not in the best interest of the vendor to disclose a bug early or even at all. Based on this alone, a Non-Disclsoure Agreement is problematic.
7.) Be up front with your intentions. If this bug is going to be a topic of a conference presentation, a blog post, or a mailing list post — say so. Tell the vendor up front what your plans are so they can respond accordingly.
8.) Understand that your timeline will almost never be consistent with a vendor’s timeline. The notion that a bug can be fixed, tested and released in 30 days is not all that realistic. That said, communicate your expectations and be prepared to at least hear the vendors side of the story. You do not have to agree or even understand but you should at least be informed.
9.) If the vendor’s timeline is not acceptable to you, be up front and say so. It won’t change the vendor’s mind but at least they won’t be surprised when you move forward with your release plans.
10.) Try to remain professional while interacting with the vendor no matter what their response. While drama and fights make for great press stories it does nothing to help get the bug fixed and nothing to help build your reputation as a researcher.
11.) Assume that the more people you tell about the vulnerability the higher chance of that issue becoming public before you are ready. Use encryption and keep your list of those you tell to a very limited need to know basis.