#include

Full disclosure of vulnerabilities?

This text is inspired by a discussion on bugtraq.

  1. Without full disclosure of computer vulnerabilities the next time the authors of an exploit may be the same guys that discovered the vulnerability, so your no-disclosure policy fails anyway, while it creates the condition to make the next worm more aggressive, see the next points.
  2. Full disclosure provides a lot of information to the comunity and expirience to make better protecion, more secure code and security culture around the world. It also creates the 'case' and the customers will think that maybe that vendor does not provide very secure code. This should stimulate the vendor to write better code.
  3. The lack of full disclosure and proof of concepts exploit helps to create an unsane security feeling about the actual software. Sysadmin will probably be less responsive upgrading they systems so when we reach the point 1 the result is very catastrophic.
  4. A motivated attacker can obtain information about the vulnerability anyway, examining the patch in the case of Open Source Software (or the differences between the last and the current version), so non-disclosure works only for proprietary software, without to consider that it is anyway possible to guess informations about the vulnerability with two different binaries (one patched the second vulnerable).
  5. The Code Red worm is pretty much a carbon copy of a previous worm released months before (one that worked on .htr files). The patch for the problem was released long ago and should have already been applied by security-conscious admins... which says something about the importance of security to most admins.
  6. Vendors - including but not limited to Microsoft - have a history of quietly burying critical problems that aren't fully released to the public. Intel initially claimed that the Pentium math bug didn't affect enough people to merit a fix; Microsoft originally claimed that NTFS was not vulnerable to file fragmentation; the list continues ad infinitum. Nothing is better for the public's interest than full disclosure; it forces (sometimes painfully) people to confront problems and deal with them.
  7. There is no such thing as partial disclosure. If you try to release nearly no details, then someone else will smell blood, and figure out the original hole, or find a new one in the same area that they will assume is the original hole. Go read about the RDS hole. If you try no public disclosure, and only release to the Right People, it will leak
  8. It has been found out that the disclosure of the vulnerability did not lead to a significant increase in intrusions. What did lead to a significant increase in the intrusion rates was the release of an attack script - the automation of the vulnerability. These conclusions were reached by studying several intrusion sets. The full paper was published in IEEE Computer in December 2000.
  9. Given the contents of an advisory that does not contain full disclosure and a decent debugger, identifying and developing an exploit for the overflow is not overly difficult. Potentially time-consuming, but not terrible complicated.
misc # Local variables: # mode: indented-text # end: