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

Code Red Shouldn't Worry You

[Greyfox]

My concern is not code red or the Moris worm or any other piece of malware that's been discovered. My concern are the ones who haven't. The designers of code red didn't make any effort to make sure their worm was stealthy. Had they done so, they could have had their code quietly running inside pretty much everywhere without anyone ever noticing. Just from a corporate espionage standpoint, that's a scarey thought. Never mind all the other nasty stuff you could do with full control of computers everywhere. And code red wasn't stopped long by firewalls, at least where I work. All it takes is for one user to get compromised and then dial in to the internal network without rebooting. At least one obviously did.

How does this relate to the topic, exactly? Well full disclosure makes it easier to find, prevent or fix the ones who might be hiding. If application foo has a hole and a few people know about it, it's easier for one of them to quietly exploit it, possibly for years. And the quiet exploits are much, much more dangerous than the ones that are quickly discovered.

I expect that companies will start lobbying Congress to make security disclosure illegal. Those will be the companies you want to avoid if you want your company's network to be secure.

More info

[GeorgeH]

There was an interesting post about this on the Politech list, which includes a response from Elias Levy (the guy who runs BUGTRAQ).

Past history can tell

[jsse]

Wouldn't it have been much better for eEye to give the details of the buffer overflow only to Microsoft?

That is based on the assumption that Microsoft would take immediate action for the benefit of the society.

Ok, take a look at this:
The update, which amounts to a point release for both IIS 4 and IIS 5, also addresses five previously undisclosed vulnerabilities with IIS, which could result in either denial of service or privilege elevation.

Five undisclosed vulnerabilities! Smart crackers might have enjoyed exploiting them for months!

When would Microsoft disclosed fixes of those vulnerabilities? Next Service Patch? Does it mean they wouldn't be fixed if not for this CR instance?

How could you rely on a group of people whose actions are unaccountable?

Ok, you can mod me troll now if you don't like I speak ill of Microsoft.

Old News

[looie]

First of all, this email and the ensuing fracas are old news. If they haven't already been covered on slashdot, then that just shows that people here are behind the curve. It's been gummed to death in numerous other places.

Second, eEye already pointed out that the author of the email actually knew nothing about the issue, as the exploit had been used months before they posted their description.

Here's part of a response to that email, from an employee of eEye:

Lets get the facts straight. CodeRed is based off of another worm that was written for a .htr ISAPI buffer overflow. CodeRed is an almost identical copy of the .htr worm. A worm which was released back in April. A worm which exploited an UNPUBLISHED vulnerability within IIS which was silently patched by Microsoft without notification to anyone. Therefore IDS vendors never had a signature and the .htr worm went unnoticed. To bad a security company had not found the flaw, then there would have been details, signatures made, and IDS systems would have detected the first instance of CodeRed back in April.

Okay, so the guy who wrote the letter blaming eEye was a fool, who spouted off without possession of any facts in the case. But, it looks like he has a lot of company on slashdot. Maybe, they ought to rename the site 'slashdork.'

mp

Re:My problem with this.

[WNight]

Actually, patching your server is one of the worst things you can do, if you aren't careful.

It depends on the OS, the severity, the size of the fix, and how easy it is to block in another way.

For an open source OS, with a simple fix, where you can look at it and be reasonably sure the patch is secure, go for it if the bug is serious.

For a closed-source OS, or a really complex patch, don't apply it until you've seen reports from people who do (give it a month or two) unless it's a huge bug and you can't block it with another method.

For example, some bugs would be port 139 overflows. Don't just patch Windows, firewall port 139 from the outside world.

Another example, Code Red... Use a filtering proxy/firewall to dump any port-80 traffic that requests "default.ida"

Keep in mind that patches aren't tested very well, simply because of the urgency of releasing them. I wouldn't trust an alpha-kernel on my servers, why would I try a webserver with an alpha patch?

This is especially important if you're working with a Microsoft system. They'd got a lot of history of releasing buggy service packs that can't be properly rolled back, etc.

THis is why full-disclosure is *essential*. Compotent admins can implement their own fixes while they wait for something official (and tested) to be developed.

Imagine if Code Red was describes only as a buffer overflow... It wouldn't be possible to protect yourself from it.