Disclose information about vulnerabilities? Yes/No/When?

The basis for this discussion

The disclosure

Last week a researcher from Google, Tavis Ormandy, posted information about and exploit code for a new vulnerability in Microsoft's help and Support center.

Norman sent a security advisory about this 11 June, and this was one of the reasons why Norman's Threat level was elevated to Medium the same day.

Ormandy's information was posted on a full disclosure mailing list, see this posting, which caused quite a lot of controversy. The main reason why is that he disclosed his findings only five days after informing Microsoft.  In the posting he writes:

(...) Microsoft was informed about this vulnerability on 5-Jun-2010, and they confirmed receipt of my report on the same day. (...) I've concluded that
there's a significant possibility that attackers have studied this component, and releasing this information rapidly is in the best interest of security.
Those of you with large support contracts are encouraged to tell your support representatives that you would like to see Microsoft invest in developing processes for faster responses to external security reports.  (...)

Finally, a reminder that this documents contains my own opinions, I do not speak for or represent anyone but myself.

Microsoft's response

Soon after this posting Microsoft released a Security Advisory with vulnerability details, and information about a workaround. A workaround fix was also soon offered from Microsoft.

Microsoft was quite harsh regarding what the company viewed as irresponsible disclosure of this vulnerability.

Mike Reavey, Director, Microsoft Security Response Center (MSRC) writes in a blog posting 10 June:

(...) This issue was reported to us on June 5th, 2010 by a Google security researcher and then made public less than four days later, on June 9th, 2010. Public disclosure of the details of this vulnerability and how to exploit it, without giving us time to resolve the issue for our potentially affected customers, makes broad attacks more likely and puts customers at risk

One of the main reasons we and many others across the industry advocate for responsible disclosure is that the software vendor who wrote the code is in the best position to fully understand the root cause. While this was a good find by the Google researcher, it turns out that the analysis is incomplete and the actual workaround Google suggested is easily circumvented. In some cases, more time is required for a comprehensive update that cannot be bypassed, and does not cause quality problems.

We recognize that researchers across the entire industry are a vital part of identifying issues and continually improving security, and we continue to ask researchers to work with us through responsible disclosure to help minimize the risk to customers while improving security. (...)

In Microsoft's Security and Defense blog this criticism against the Google researcher is also mentioned:

Yesterday evening, one of Google’s security researchers publicly released vulnerability details and a working exploit for an unpatched vulnerability in Windows XP and Windows Server 2003. (...)

These two comments illustrate that Microsoft went quite far in associating Ormandy and the company he works for - Google, which led many to speculate whether this was another example of the ongoing controversy between two of the world's biggest IT players.

An everlasting debate

The discussion between those who advocate full disclosure of vulnerabilities and those who want the software vendors to have "appropriate" time to offer a remedy, has been going on for ages.

Norman's security articles have briefly touched the subject several times. We have not however discussed this in detail since our article in 2002 - The dilemmas of publishing information about vulnerabilities in software. It now seems appropriate to repeat some of the points of view.

In short the two camps advocate the following standpoints:

The full disclosure camp:

When one or few know about a vulnerability most likely others do too. Disclosing the information is therefore the best, so everyone can set up the necessary protective measures.  Exposing a vulnerability to the public domain also forces the vendor to address the issue faster than otherwise.

The responsible disclosure camp:

Publishing details about a software vulnerability notifies a wider audience, and thereby increases the risk for exploitation by someone with malicious intent. The vendor of the software should always be admitted time to investigate the vulnerability, and build and test a patch thoroughly. This will benefit all parties.

Both points of view have obvious merits. It is no doubt that publishing exploit code about a vulnerability often will tempt malicious persons to create malware based on this information. There are numerous examples of malware that materializes soon after an exploit has been published. The particular issue that is mentioned above is a typical example: Very few days after disclosure, malware that utilized the exploit was seen in the wild.

The argument that full disclosure ensures faster remediation on the other hand, is easy to defend, and can be substantiated with lots of examples. The many out-of-band security updates of software from Microsoft and Adobe are typical examples.

There have been initiatives to agree on a standard policy for disclosure, which could be a kind of compromise between the two different views mentioned above. Our previous security article mentioned above, mentioned an organization set up for this - Organization for Internet Safety. This organization does not seem to be active any more, even though entering their web site displays the document "Guidelines for Security Vulnerability Reporting and Response". The document is hosted by Symantec, one of the founding members.

Microsoft's "Responsible Disclosure Policy & Acknowledgement Policy for Security Bulletins" should be mentioned as another example of a disclosure policy that many adhere to. Not surprisingly this is a typical example of a "responsible disclosure" document.

The "rfp policy", which was also mentioned in our 2002 article, still has its advocates. This policy might be viewed as residing in the full disclosure camp, although it absolutely advocates responsibility on the hand of the finder of the vulnerability. It stresses that the program vendor also has obligations to the person who first reported the vulnerability.

Finally we will mention the CVE web site (Common Vulnerabilities and Exposures) as a useful place for information about vulnerabilities. CVE provides a standard for identifying different vulnerabilities. For example is the vulnerability that was introduced at the beginning of this article uniquely identified as CVE-2010-1885. The CVE web site also offers interesting documents, dealing with different topics relating to vulnerabilities.

Norman's view

As Norman sees it, the crucial point regarding disclosure is

to minimize the risk for users to be exposed for malware. 

A consequence of this view is that a person who discovers a vulnerability should inform the vendor and cooperate during the time the vendor needs to create a solution (usually a security patch) to the vulnerability.

However, at some point in time the risk that other persons may discover / have discovered the same vulnerability and may/have created malware, becomes bigger than the advantage obtained by remaining silent. This point in time does rarely arrive as soon as five days, the time granted Microsoft in the case discussed above.

At which point in time this will happen differs based on several variables, and should be one of the topics for discussion between the person who has found the vulnerability and the vendor of the exposed product.