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:This is absurd

[Remote]

My hunch is that, given the fall in the overall level of opinions posted in Slashdot over the last months, Hemos is dilligently bringing up such absurd questions so as to educate people who, although misinformed, can spot good advice when exposed to it. :)

Security through intimidation

[Anonymous Coward]

You can find new security holes in NT automatically. Microsoft has tried to hush this up. The famous NTcrash program is an illustration of this. Microsoft leaned hard on the originators of that program, who were non-Microsoft NT internals experts, to suppress it. That program, which makes random system calls, demonstrates that NT 4 security was inferior to NT 3.51 security, and that NT4 had bad code borrowed from Windows 95 in the kernel. Microsoft didn't like that. It's very hard to find a copy of that program on the web. Watch that link disappear.

NTCrash does more than make random calls; it stores what it's doing before it tries it, and after the reboot, avoids doing that again. So after a while, and many crashes, you accumulate a log of new vulnerabilities.

There are later variations on that theme which find more subtle holes. Rather than just making random calls, it's more useful to permute valid calls slightly. That's been tried successfully.

The classic paper on this subject is The Tao of Windows Buffer Overflow, from the Cult of the Dead Cow.

Considering that all this was known five years ago, there's no excuse for Microsoft products having any buffer overflow vulnerabilities. This falls between "gross negligence" and "reckless endangerment". Where's the plaintiff's bar when you need them?

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.