Archive for vulnerability

Apparently Time Has Reversed – Not The Disclosure Debate Again?!?

Posted in security with tags , , , , , , , , , , , , , , on April 23, 2010 by hellnbak

Remember  back in 2001 when researchers were compared to Terrorists and the term “Information Anarchy” was coined?  You can read this blast from the past here –>

As the saying goes, those who do not learn from history are doomed to repeat it, or something like that we have this clueless blog post over on the Verizon Business Blog –>

The gem of this post is:

“Narcissistic Vulnerability Pimp: One who – solely for the purpose of self-glorification and self-gratification – harms business and society by irresponsibly disclosing information that makes things less secure.”

Sigh.  Really?  One would think that a business with the word “Intelligence” in it would actually show some.  Meanwhile we all know that the “intelligence” is nothing more than a bunch of drones monitoring IPS logs and being yelled at when the technology they have pimped out does not actually detect a real world threat.  So instead of actually attempting to improve things it is much easier to point fingers, call names and attempt to blame researchers.

Researchers *DESERVE* credit for their finds because while they are causing short-term pain (short-term pain Verizon Business is able to invoice clients for) they are affecting long-term changes.  History has proven, when a vendor gets tired of being hammered by security issues that vendor starts taking security seriously and begins to improve.  Let us not forget that the majority of researchers do this FOR FREE, so giving them some resume fodder and recognition should not be such a big deal.

Verizon Business’ entire business model falls apart if it was not for these so-called “Narcissistic Vulnerability Pimps” giving your drones something to submit billable hours for.  Or how about the fact that Verizon Business themselves have and may very will still employ the exact people they are attempting to point fingers at.  I know for a fact that at one time (maybe still) a couple very high-profile “Pimps” were receiving paychecks from Verizon.

I am totally stealing this comment from Charlie Miller’s twitter ( but based on this blog post — Verizon Business are the whores that the vulnerability Pimps peddle to.  Given the choice of being a pimp or a whore I would pick pimp any day of the week, the wage is better, the benefits are better and who doesn’t like smacking a ho once in a while?

Lets back up a second and try to determine exactly what Verizon is complaining about.  I suppose they are trying to point out the difference between a researcher that follows responsible disclosure vs one that does not.  So why the silly name calling?  Why not just simply put it that way.  There are those that believe in responsible disclosure and there are those that do not.  Kind of simple isn’t it?  Oh wait, that does not make for a good blog post to generate some attention and traffic — much like this one.

While I am ranting about what is probably the most ass backwards blog post this year I might as well share my opinion on the whole disclosure thing and yes I do truly believe that this is beating a dead horse as there will never be an opinion that is completely correct.

There was a time, especially around the 2001 timeframe, when I believed that reporting a bug to a vendor, then giving said vendor a set amount of time (30 days in my case) to fix a vulnerability was the right thing to do.  After 30 days expires, release full details on the vulnerability and move on. 

Over the years, and as I began to work for various software and hardware vendors, my thoughts on this slighty changed putting me more in the responsible disclosure camp.  To me this means, you find a vulnerability, you report it to the vendor and you wait for the vendor to patch before releasing your independent advisory.  The severity, based on ease of exploitation and impact of exploitation, of the issue dictates how much information to release on the issue as the whole point is to actually help increase security.  The only caveat I have to this is that I also believe that if a vendor is refusing to patch an issue, not taking the issue seriously, or someone else finds the issue and uses it publically then all bets are off and it is better to simply drop all details so that those in the protection business have a level playing field. 

In fact, the only reason I am against the whole “No More Free Bugs” movement is because if you privatize and monetize the reporting of vulnerabilities, you remove the ability to hold a vendor truly accountable by having the ability to simply “drop zero day” on them to force a fix.  Once you enter in to contracts and start accepting money for vulnerabilities — you lose your ability to force change.  That said, a pimp needs to get paid.  😉

Anyways, this whole argument is stupid.  Full Disclosure works and in my opinion responsible disclosure is a safe compromise as long as the vendor is playing along.  Verizon Business is truly biting the hand that feeds them.


Taking Responsible Disclosure for Granted – Part Duh

Posted in security with tags , , on January 3, 2010 by hellnbak

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

Posted in security with tags , , , , , , , , , on October 24, 2009 by hellnbak

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.