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.

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.

NoMoreFreeBugs – ohnoes!

At CanSecWest last week (note to self: write a post about how awesome the conference was) a few well known researchers, Alex Sotirov, Dino Dai Zovi, and Charlie Miller began a movement against “free bugs”.  The basic and over simplified premise is that they feel that security vulnerabilities should not be handed over to vendors for free.  I don’t necessarily agree with this but in reality who cares?  To each their own.  This is really an individual choice.

Of course, this caused a few to scratch their heads and while I am sure there are other really dumb blog posts about this — I thought this one took the cake:

http://www.sophos.com/security/blog/2009/03/3680.html

Not only is the above blog post completely off the mark, but it is clear that the author is very inexperienced in dealing with security vulnerabilities.  Lets look at some of the ridiculous comments made by Ross Thomas of Sophos.

“As one of those users, I have to say I’m not exactly delighted to discover that a so-called security researcher was so breathtakingly cavalier about the safety of my data and the privacy of my personal information. Apparently I’ve been vulnerable to this “idiot-proof” exploit for at least a year, and have only good luck to thank for the fact that no-one used it to drain my bank accounts in the meantime.”

Wow.. talk about raising the level of FUD and so soon in the post.  While we don’t have a heck of a lot of details on the bug (some do have more than others) I can say with a pretty high confidence level that this bug could not be used to “drain” the author’s bank account.  If it could, there would be even less reason to disclose it. 

But wait it gets even worse:

“The point I’m trying to make is that this wasn’t “his exploit” to do with as he saw fit.”

Really?  Didn’t the researcher, in this case Charlie Miller, spend the time to find this bug?  He found the bug and he wrote the exploit.  That does in fact make it his to do with as he pleases.

I guess that is really the entire point that Sophos and Ross Thomas are missing.  While I personally would report any vulnerabilities I find to the vendor, for free, it really is up to the individual researcher to do as he pleases with what he finds.  Afterall, he did put in the work.

“With today’s highly monetized black market for malware authors this kind of bug must not be permitted to exist even for a day, let alone a year”

More FUD!  Security vulnerabilities exist, they always have and they always will.  Get over it.  Bugs exist much longer than days as it takes most vendors months to fix anything and once you have reported the bug to a vendor — it is no longer a secret.  While anyone could have found the same bug and used it for “bad things” no one did.  So what does that tell you?  It suggests to me that the so called “black market” and malware authors aren’t looking as hard or maybe they aren’t as good as looking.

Lets also not forget that users are always slow to patch their machines.  So waiting to report this really has no bearing on anything — especially when this specific bug has not been used in the wild.  Looking at the last few very successful pieces of malware — none of them used a zeroday.  In fact one of the bigger ones (although we all know the shady AV Vendors inflate their numbers) Confiker, used a known and patched vulnerability.  In fact, the trend lately has been, patch released, bad guys reverse patch, bad guys start using vulnerabilities, months later users get around to installing patch.

Perhaps once we start to see more actual zero day being used and lets be honest here, perhaps once AV Vendors start actually offering their users REAL PROTECTION that can’t be easily bypassed then we can cast stones at someone for wanting to be paid for something they do in their spare time.