Thoughts on responsible disclosure

Years back, software vendors coined the term ”Responsible disclosure”. Responsible disclosure is loosly defined as reporting a vulnerability / security defect directly to the software vendor, which then fix the vulnerability.

However, Responsible disclosure has key differences to older inititives, such as RFP Policy Rain Forest Puppy’s Full Disclosure Policy (now also dubbed as a Responsible disclosure policy) is that more or less much of the ”responsibility” is about security vulnerability finder (e.g. Pentesters, security researchers, etc) not to disclose what they know to the public.

Very little of the software vendors interprentention of ”responsible” is their part of the effort. If you compare this to the RFP Policy, which clearly defines vendor responsibility, major differences becomes obvious:

D. If the MAINTAINER goes beyond 5 working days without any communication to the ORIGINATOR, the ORIGINATOR may choose to disclose the ISSUE. The MAINTAINER is responsible for providing regular status updates (regarding the resolution of the ISSUE) at least once every 5 working days.

So, the RFP Policy mandates communication and transparency from software vendors, where as software vendors does not interpret responsible as such.

RFP Policy also mandates that vendors provide some soft of credit to finders for their efforts;

E. In respect for the ORIGINATOR following this policy, the MAINTAINER is encouraged to provide proper credit to the ORIGINATOR for doing so. Failure to document credit to the ORIGINATOR may leave the ORIGINATOR unwilling to follow this policy with the same MAINTAINER on future issues, at the ORIGINATOR’s discretion. Suggested (minimal) credit would be: ”Credit to [ORIGINATOR] for disclosing the problem to [MAINTAINER].”

Lately, we have seen plenty of examples of security teams rejecting to cooperate under Responsible disclosure as defined by vendors. This is typically referred to irresponsible disclosure. Sometimes it is also called a zero-day, although it kind of seems like a improper  choice of word for a vulnerability if it has been known for severals days (weeks, months, or even years) by vendor.

As the number of non-conforming security researchers increase, I do believe one of the most important aspects is vendors failing to provide the transparency that was mandated by the RFP Policy and the full disclosure movement. Long resolution times is certainly a contribution factor as well.

However, it seemed to be a clear distinction. Security researchers conformed to vendor defined responsible disclosure practices, and the few that didn’t were considered irresponsible rogues. Lately however, there have been much of uncoordinated disclosure, and prominent security researchers – such as Google’s security engineers – have broken with software vendors. With some draconian and chilling comments from vendor and press.

I must say, I’m not very convinced that vendor defined responsible disclosure is working. I do understand that working as a security contact at a software vendor is one of the hardest job possible, and Microsoft MSRC has probably one of the most challenging tasks possible, but anyway, here’s my story and why I do not believe in responsible disclosure any more:

  • While not performing security research, I find that a security control is failing. This was a pretty trivial find, it was easy to stumble across it.
  • For various reasons, I ignore my find for a while – I didn’t have the time to research the details. But eventually I got some spare time and invested in reading up on the documentation for the security control. Virtually all docs failed to provide sufficient information to administrators on how to configure the security control to all actually work. You could configured as explained in numerous docs, and still be vulnerable. After a while, I was getting 100% certain that this was an undocumented defect. I then invested a couple of hours in determining what pre-conditions were required for exploitation, create easy-to-understand-PoC, and also determined that a fairly large portion of the installations were affected (although the majority was safe). I’d say most security professionals would rate the vulnerability as either Important or Moderate.
  • I complete a write up of vulnerability, including all details for exploitation and mitigation, proof of concept etc and sends it to Microsoft.
  • After a while I think ”wait a minute… it cannot be possible that this trivial find has never been found before?!?”. Given my complete writeup, I determine good search key words and start googling. It was much harder than expected, but after a while I find a couple of examples where others present mitigations without stating why. That’s highly suspect and supports my idea that others must already know the control is broken. But then I find the real gem: a public mention of all preconditions necessary for exploitation and sufficient information for even a complete moron to compile an exploit. That’s it, no more googling! I complete my second mail, providing details on that the vulnerability is publicly known.
  • Response, 30 march 2010:

Thank you for reporting this to us.  We are aware of the issue you reported, but as a matter of policy, we cannot comment on ongoing investigations. You may want to keep an eye on our blog at and our advisories at, as those are the places we will release public information prior to any bulletin. If you would like to receive an email any time we release a security update, please sign up for the Microsoft Security Notification Service at I hope this helps.

So I didn’t even get any errand number. I’m not privy to information about the progress on the correction of a vulnerability I have reported. I don’t really know if the vulnerability is considered publicly known by Microsoft / MSRC, or if they even consider it to be a vulnerability. In my mind, they could just document the problem or fixed a couple of broken if-statements…

I didn’t reverse engineer the code, but I do believe the vulnerability is something like this in code:

 if(....) { performSecurityControl() } else { /* not */ }

and the condition is incomplete.

I have no way of knowing if this vulnerability has ever been exploited by bad guys. I also don’t have any knowledge of how many knows about it, but anyone can find it fairly easy, either by accident, by penetration testing, or entering the correct search phrase into Google.

Days grew to weeks, weeks grew to months, m0nths will probably grow to years before it is fixed. Unless it has been silently fixed. I’m not validating future releases, I’m contempt with feeling apathy towards vaguely defined Responsible disclosure. Unless a vendor is clearly stating that they intend to abide by non-vendor centric vulnerability disclosure model, I don’t believe it is truly responsible.

In no way am I indicating that Microsoft / MSRC is in any way achieving more poor than other vendors, they are simply performing much poorer than I expected them to. I did have high hopes for MSRC, as they often are dubbed industry leaders.  I’m kind of used to no reply, or ”most will be fixed”, ”it will be fixed in new version only”, ”this system is so old, we’ll have a new system in a couple of years or so”. But such replies are typically from less prominent software vendors.

Based on my experience, I don’t believe the people condemning irresponsible disclosure know what they are talking about. It is easy to tout a practice or process, if you are not affected by it. You have to participate in responsible disclosure to know what you are talking about.

While I do acknowledge that keeping silent about vulnerabilities might decrease negative impact (i.e. exploitation, uncoordinated patches, etc), I also believe that is partly FUD. I might also increase the impact of the vulnerability by allowing vendors to not fix a vulnerability, which then later becomes the exploit of choice in targeted attacks, or part of a major catastrophic worm.



  1. Kan det här ha med No More Free Bugs-rörelsen att göra? En säkerhetsforskare som egentligen vill ha betalt för sin forskning kommer att ha en negativ attityd till leverantörer som inte vill betala honom/henne, och kommer därför inte att ställa upp på någon Responsible Disclosure.


    1. Jag vet inte riktigt vad din poäng är. No free bugs och bug bounty är väl främst för att ge ungdommar (typiskt 15-22 åringar) ett ekonomiskt incitament att ägna sig åt buggjakt på fritiden. Några arbetslösa kanske också kan ta det som en extra inkomst. Ingen blir ju rik på att få några enstaka hundra dollar från Google / Mozilla någon gång då och då. Folk med bra fast inkomst behöver inte de pengarna.

      Själv har jag privat rapporterat in… Hum… Kanske 50 buggar som dykt upp under ”normal” användning. Läser du min blogg så ser du att reagerade på 17 minuter(!) efter att jag rapporterat till dem.

      Microsoft och många andra har problemet att deras lösningstider går åt oändligheten och att de inte förklarat sig. När en bugg släppts publik kan den plötsligt lagas på veckor eller en månad. DET skapar trovärdighetsproblem: svårigheterna att rätta en bugg tycks obegripliga, bara den blir publik försvinner problemen.

      Som i mitt fall, jag tror en defekt if-sats är root cause, borde kunna buggrättas på någon minut – eller så är det svårare, MSRC svarar inte. Eller rätta dokumentationen så att guidelines inte ger en osäker uppsättning, om de inte kan laga felet.


  2. Det finns aktörer där ute som betalar mycket mer än ”enstaka hundra dollar” för säkerhetsbuggar, men du kanske har rätt i att det inte finns någon koppling till det.


    1. Avser du försäljning på svarta marknaden så är det svårt att se kopplingen till de som publicerar. Eller betalningsprogram som ZDI, eller företags egna bug bounties osv.


  3. Jag tänker främst på ZDI/iDefense/iSight o s v. De betalar ju tusentals dollar, vilket är en del pengar för de flesta, och min poäng var alltså att om man är inne i en mindset när man vill tjäna pengar och inte i första hand bidra ideellt kommer man kanske inte att vara så benägen att samarbeta om man inte får några pengar för det.


    1. Tja, det är en svår fråga.

      ZDI m.fl. har ju som marknadsidé att få ungdomar att jobba för dem istället för ha egna anställda. De är ju mycket billigare än att ha motsvarande fastanställda erfarna. Utan att ha en koll på deras prislista så tror jag det är svårt att bli rik på ZDI, förvisso kan enskilda heta buggar ge en hel del cash, men om du inte är extraordinär så kan du inte håva fram många sådana.

      ZDI är väl heller inte direkt en representant för No more free bugs, eftersom deras pengarflöde inte kommer från vendors.

      Vi är väl ganska långt ifrån mitt blogginlägg då jag debatterade RFP från gamla Full Diclosure rörelsen, vs att delta i Responsible Disclosure helt drivet av en vendor. RFP policy innehåller bland annat dessa ställningstaganden:

      E. In respect for the ORIGINATOR following this policy, the MAINTAINER is encouraged to provide proper credit to the ORIGINATOR for doing so. Failure to document credit to the ORIGINATOR may leave the ORIGINATOR unwilling to follow this policy with the same MAINTAINER on future issues, at the ORIGINATOR’s discretion. Suggested (minimal) credit would be: ”Credit to [ORIGINATOR] for disclosing the problem to [MAINTAINER].”


      Q. You mention compensation–do ORIGINATORs expect to be paid? A. NO! (Well, they shouldn’t…I can’t definitely predict the expectations of people) Compensation, as mentioned in this policy, is meant first-and-foremost to be PROPER CREDIT. Academia has historically and religiously provided credit when referencing all types of works and research; the ISSUE provided by the ORIGINATOR should also be thought of as research, and the ORIGINATOR should be credited accordingly. Now, beyond that, it may be in the vendor’s best interest to promote good relations with the researcher, and one suggested way is to provide updates and product licenses. A lot of research is done on evaluation and trial versions of software–providing a single, full license/copy should produce little impact on the vendor, but greatly help the researcher. Another suggestion is to allow access to support sites/technical content, such as TechNet (if you happen to be Microsoft 🙂

      Dessutom var min explicta referens till just Google, och då kan man titta på lcamtuf säger om nu free bugs rörelsen:
      …han är alltså försiktigt förstående men påpekar det stora moraliska dilemmat som No more free bugs rörelsen står för.

      Min egna bugg är i min mening pinsamt uppenbar och jag anser inte att jag haft något avtal med MS eller på annat sätt har rätt till några pengar från dem. Jag skulle tippa på att tiden för att hitta hålet och skriva ner initiala observationer det kanske totalt 1 timme, och senare research för att hitta exakt när hålet triggas + bevis för att det är tidigare känt tog ca 3 timmar till. Skulle tippa på att ca 50% av det dessutom gick på arbetstid 🙂



Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in: Logo

Du kommenterar med ditt Logga ut / Ändra )


Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )


Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s