Archive for disclosure

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

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.