Slashdot Mirror
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."
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
well.. they acknowledge people who found the bugs.
Acknowledgments
Microsoft thanks the following people for working with us to protect customers:
John Waters of Deloitte and Touche for reporting the MIME type denial of service vulnerability.
The NSFocus Security Team (http://www.nsfocus.com) for reporting the SSI privilege elevation vulnerability.
Oded Horovitz of Entercept(TM) Security Technologies (http://www.entercept.com) for reporting the system file listing privilege elevation vulnerability.
There was an interesting post about this on the Politech list, which includes a response from Elias Levy (the guy who runs BUGTRAQ).
Why can't I moderate something "Wrong" or at least "Grossly Misinformed"?
The letter is very well written and I agree with the author. My only critiscsm is that Microsoft does not have a good system for accepting such advisories. Its always been my experience that you have to pay Microsoft to listen to your complaints/concerns about their software.
Maybe eEye tried to tell them but they didn't listen?
there are 2 kinds of people. those who divide people into 2 kinds, and those who don't.
This is such a blatant antagonism I can't believe it's still making the rounds. The note was posted to Bugtraq and has become the poster child for the anti-full-disclosure crews.
Slashdot is trolling us--successfully, it looks like. Too bad we can't mod the story itself down!
This debate is hashed through time and time again, and solved--time and time again. Anyone who argues against full disclosure has never been a system admin or been deep enough into someone else's exploit-ridden code to feel the pain.
Exploit disclosures are like the work-saving packages collections of *BSD. Someone else has done the work for you. For those who are in the know this means we don't have to fire up our own copy of IDA or grep spaghetti source code to figure out what the heck is going on.
Why should I worry about the lower forms of system admin life and hold their ignorant hands when my more important systems and the systems of my clients are at stake? If you can't stand the heat, bloody well get out the kitchen and leave the work for someone who knows what they're doing.
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.
Agreed. Today Microsoft released a cumulative fix for IIS 4 and IIS 5. They fix five previously unknown bugs, as well as some known ones, including the Code Red hole. Anyone want to bet that programmers at Microsoft are the *only* people who knew about these holes? Perhaps they were tipped off by some White Hat hacker, but more likely they discovered the hole from an intrusion attempt.
eEye's response,
http://lwn.net/2001/0816/a/eeye.php3
clearly points out that they provided *NOTHING* to the virus writer, and in fact the virus writer used another virus as a template. The criticism in this
case is quite unfounded.
What's the world coming to when everyone's favorite security guru starts blaming the messenger, too?
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
"The secret to strong security: less reliance on secrets." -- Whitfield Diffie
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.
VMS allows instructions on the stack to be executed. That capability is used in some complex programs that generate machine code for execution "on the fly".
VMS does not have a history of buffer overflows.