Sandi brings up the question of responsible disclosure.

Over in Sandi Hardmeier's blog, I see again that a site was hacked following a public disclosure of an exploit, but prior to the availability of a patch. Sandi says:

This makes me ponder the ongoing argument about "responsible disclosure". Should Gulftech have publicly announced the exploit?

Of course Gulftech should have publicly disclosed the exploit ... after Invision released a patch, and after a majority of Invision's aware customers had a chance to apply it.

If these companies really care about "I was first" bragging rights, they can cryptographically sign and timestamp the document, release the signature when they first have a private document describing the exploit; then they can release the document after the patch, and we can all recognise that their signature matches the description of the exploit, and marvel in how smart they are to have found the exploit before anyone else.

There is one concern here, though - when public disclosure happens, the discloser can throw up their hands and say "it wasn't us that wrote the virus - must have been some member of the public". If the researchers stop public disclosure until after the patch, any pre-patch virus that comes out might cause the researchers to be suspect number one.

I don't think that's a reasonable fear, though, because such researchers would be beyond reproach, compared with researchers who publicly disclose prior to vendor patches, who are quite definitely and deliberately giving the exploit details to virus authors.

Published Mon, Jun 5 2006 7:51 by Alun Jones
Filed under:

Comments

# re: Sandi brings up the question of responsible disclosure.

Alun.  Good topic - I've always been puzzled by the "disclose at any costs" mentality.  I think folks generally "get" the original motivation for public disclosure to shame vendors into doing the right thing.  However, once vendors start actively working to fix issues, then responsible disclosure becomes a much better process for reducing risk.

I suppose the core dispute is trust though.  If I look at the allegations against how long Oracle sits on responsibly disclosed issues, for example (and if it is true), I begin to doubt someone is working hard to fix issues.

These are the same allegations that get levelled at us, even when I know we're working hard to fix issues and get something out in 7 days (WMF...) ...

Monday, June 05, 2006 11:23 PM by Jeff Jones

# re: Sandi brings up the question of responsible disclosure.

Let us return to the days of yesteryear where security vulnerabilities were reported to CERT, who would pass the report to the vendor to resolve when or if they found time to work on the issue. The vendor would obviously be aware if vulnerabilities were being actively exploited in the wild and would respond in the most appropriate fashion for the situation, should such unfortunate events transpire. The Systems Administrators would not be aware of issues with the systems they oversee, nor should they know for they may be part of the problem. The job of the Administrator should be to follow the advice of their vendor; potential workarounds may cause other issues and complicate matters, and thus should not be implemented, discussed, or disclosed. Security researchers are only interested in getting credit for their findings, and thus their work can wait until the vendor has approved the release of their information.

That type of thinking is what led to the Full Disclosure movement. Any extreme will have problems (Vendor Only Notification vs Full and Total Disclosure). Responsible Disclosure (the prevailing method of Full Disclosure) looks to be the best system so far.

Of course Gulftech should have publicly disclosed the exploit, if they thought disclosing that information would lead to a better security environment than waiting for the vendor (e.g. if they felt the vulnerability was being exploited in the wild).

Would you rather know, or not know?

Friday, June 09, 2006 5:54 PM by Bucky

Leave a Comment

(required) 
(required) 
(optional)
(required) 
If you can't read this number refresh your screen
Enter the numbers above: