Public Disclosure

Many bug finders want to share the details with the security community through mailing lists such as Bugtraq and Full-Disclosure. The details of the vulnerability and how it was found can help others understand the issue, find related bugs in other products, and build exploits. See the dilemma? How can good guys further research without enabling bad guys? Two areas of discussion are the amount of detail to include and when to disclose it.

Deciding on the Amount of Detail

Bug finders often include details about the impact of the bug, affected products, how they found the bug, and anything unique about the bug that might assist other security research. Bug finders sometimes include proof-of-concept (PoC) exploit code that demonstrates how the vulnerability can be exploited. Sometimes the PoC is written in such a way that an unskilled attacker can compromise the target machine by simply entering an IP address. These attackers might not have the technical understanding of the flaw to exploit it based on the details alone, but can use user -friendly exploit code as described. Is it a good idea then to suppress exploit code? Exploit code is useful for legitimate purposes. It certainly proves there is a problem and with exact details. These details enable others to better understand how a certain type of issue could be abused.

In the past few years , many bug finders have stopped providing PoC or provide a more limited PoC. The creators of Code Red and SQL Slammer, two infamous worms, used PoC code as a template to exploit a specific vulnerability. David Litchfield, a talented bug finder, found a buffer overrun in Microsoft SQL Server. He publicly presented exploitation techniques for this bug. These details were later used to create the SQL Slammer worm. When he presented the details of the bug, Litchfield wanted to help security research, not cause harm. After it became apparent that his code was used as a template for creating the worm, he said, At the end of the day, part of my stuff, which was intended to educate, did something nefarious, and I don t want to be a part of that. Examples like this have caused people to stop releasing PoC or to release only a more limited PoC. David Litchfield no longer distributes any PoC code.

Important  

If you re a software vendor, don t think that because the original finder decided not to release exploit code that it isn t available. Public projects such as the Metasploit Project ( http://www.metasploit.org ) specialize in creating reliable exploits that are free and easy to use. You also never know what people have created privately.

Timing the Disclosure

Responsible disclosure is done after a security patch has been released. Some finders disclose all information about the bug they found on the same day the patch is released. This illustrates the importance of installing the patch quickly because attackers, previously unaware of the flaw, have information on the bug before most people have had the opportunity to install the patch. To give people time to install the patch, immediately following patch availability some finders release only information that there is a bug, its impact, and that a patch is available. Later, more details about the bug are disclosed. Microsoft recommends waiting 45 to 60 days before disclosing complete details.