On The Costs of Full Security Disclosure

sasha328 writes "I found reference to this email on the LWN.NET site which was sent to the SecurityFocus mailing list. It asks a very valid question about how much you can disclose before malicious virii can be possible."

Comments

Re:Sometimes you need to bring out the sledghammer

[hAkron]

Well in this case I agree that maybe a total disclosure from eEye was a bit of a conflict of interests, here is an analogy to illuminate my point. Suppose that ADT (or some other home/commercial security company) had a flaw in their security systems which actually made it easier for you to break in to a home/business. It would be one thing for a news reporter who is doing an informational story warning people that a flaw exists, it is quite another thing for a 3rd party company who sells add ons for the security companies systems to give potential wrong doers step by step instructions on how to exploit this flaw. This is basically what eEye is doing, if you notice, on the same URL where one can find the free Code red detection tool there is a link to their secureIIS web product. Basically they have released damaging information to stimulate sales of a product they produce...not exactly ethical.

UCITA's effect on bug-reporting

[Masem]

Another factor to add in is how UCITA (and to some effect, DMCA) will affect the reporting of bugs. Of the key provisions in that legislation is that a company could make it against the law via the click-through license to 'critique' the software package without permission or to try to reverse-engineering protocols. Since many security bugs are typically found in either of these two activities, it may be illegal to simply access the security of a piece of software, or at least to access and release those results to the world. Which is another reason to make sure that if your state is considering UCITA to emphasis that it will hurt the security sector and could prove harmful in the long run.

Re:More info

[Salamander]

In that thread, Richard Smith asks:

How should third-parties develop countermeasures?
...
How should authors of vulnerability scanners and intrusion detection systems obtain information to produce new signatures?
...
etc.

By limited disclosure. Yes, Virginia, there is something between sweeping something under the carpet and laying out all the gory details for everyone (including other would-be virus/worm writers) to see. If a security-product vendor had information that would help their colleagues create barriers, signatures, etc., they could share that information with those colleagues - without having to share it with the entire world. They could release enough information publicly to allow one "skilled in the art" to create countermeasures, without providing a step-by-step recipe that even the relatively unskilled could use to create new exploits. There's no need to reveal *everything* to *everyone*.

So why don't vendors do this? Do they not have faith in their colleagues' discretion? Hmmm. Do they not have faith that their colleagues can develop countermeasures based on partial information faster than black hats can create new exploits? Hmmm again. The *real* reason why they prefer full disclosure is discussed in one of my other posts to this thread.

Smith goes on to say:

What it boils down to is this: disclosure of detailed vulnerability information benefits security conscious people, while, in the short them, hurts people that do not keep up with security

BZZZT! Wrong. The security-conscious people can get that benefit without full disclosure, with less risk to the security-naive rabble. Of course, it's in security companies' interests that security-naive people should get hurt, making them less security-naive and more likely to buy products or services from companies such as the one of which Smith is CTO. I sure am glad that I'm not in a business where making sure people get hurt is part of the business plan.