Monday 24 November 2003

Exploit Codes and the Motivation to Patch

Security Focus reports that:

Security pros gathering at a Stanford University Law School conference on responsible vulnerability disclosure Saturday harmonized on the principal that vendors should be privately notified of holes in their products, and given at least some time to produce a patch before any public disclosure is made. But there was pronounced disagreement on the question of whether or not researchers should publicly release proof-of-concept code to demonstrate a vulnerability.

However, this agreement implies that vendors will patch their products once notified of security holes and before a proof of concept is released.

In reality, this has not always happened, or we wouldn't have unpatched internet explorer bugs doing the rounds and I specifically remember Eeye Digital Security and Secunia putting pressure on Microsoft to close the Object Data Vulnerability which was left unpatched in MS03-032 but was later patched in MS03-040.

If Secunia and Eeye had kept quiet, how do we know that Microsoft would have patched those holes in time?

If I recall correctly, MS03-032 was released on August 20, Secunia and Eeye made their exploits available on the same date proving that the patch was incomplete and MS03-040 was released on October 03.

How long would this have taken without public disclosure?

These proof of concept exploits are dynamite in the hands of hackers but on the other hand, proof of concept exploits are quite useful in the open source community where anyone can contribute to the source code of programs. I believe that making them public can only help secure these products in the long term though I admit that it doesn't benefit software whose source codes are not available to all.

The Security Pros also agreed to withhold proof of concept of the exploits for at least 30 days after a bug is made public but in my opinion, this is not motivation enough to patch these holes and vendors would most likely put a PR spin on these bugs and market them as FUD in addition, there is the danger of leaks in the community and inevitably hackers will find a way to create these exploits themselves.

Perhaps there also ought to be a score card kept of vendors which patch their softwares. The score card will be weighted depending on the complexity of the bug and how soon it is patched and made available at an agreed schedule.

What I am trying to say here is that there ought to be a way to make these vendors accountable for their softwares and also a way to keep end-users informed about the softwares they implicitly trust.

Related Entry