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

Don't release Security Updates!

[friscolr]

Releasing Security updates is tantamount to full disclosure - any blackhat with a bit of knowhow and enough time will be able to reverse-engineer the bug (no DMCA regs, please, we're talking about blackhats here).

So, since releasing a security patch is equivalent to giving the blackhats full disclosure, no software should ever be patched again. Instead it should be understood that anytime anyone finds a security hole, they need to be quiet forever.

Sex Education

[lcypher]

Arguments against full disclosure are like arguments against sex education. Sure, there is this thing called 'sex', but we aren't going to tell you how to do it, or how to protect yourself. The whining about eEye overlooks one important aspect: CodeRed was not written by a script-kiddie. It may have been deployed by a script-kiddie, but it definitely was not written by one.

Let's say that eEye just released an advisory that said there was an overflow in the processing of default.ida. No more information than that. It would not take a skilled hacker very long to find the buffer overflow, and then exploit it. It doesn't matter if eEye says little or everything. The skilled hackers are going to find the hole themselves.

I believe the current system works as well as it can and should. When somebody finds a bug, they usually report it to the company, let them play with it for a week or so, work up a patch or workaround, and then it is posted publically on Bugtraq or some such list. Then somebody might write a proof-of-concept or an exploit, but will leave one part intentionally broken here or there so only people that can read the code and understand what is going on can fix it and use it. Bugtraq keeps companies accountable for their products security. Without it, there would definitely not be the same diligence at most companies responding to security concerns.

If you are going to teach sex, don't just say 'save it for marriage'; teach about condoms so people aren't caught with their pants down.

Re:Sex Education

[coolgeek]

windowsupdate.microsoft.com is not protecting your servers. M$ does not update the windowsupdate.microsoft.com server regularly to include security patches. Check this recent wired article, Steve Lipner (M$ security response center mgr) sez don't use windowsupdate for security patches.

the "Full Cost" argument is flawed

[G Neric]

The letter makes an argument based on the supposed "full cost" of the full disclosure of security holes. Unfortunately, this argument is hopelessly flawed from an economics perspective because he did not consider the cost that diminished awareness puts on the future.

It was not till exploits started being written, and even further after there were some major epidemics, that unix admins and programmers tightened up on security. (sendmail? ftpd? bind? sheesh!)

Did Microsoft learn anything from these previous incidents? Yes, but very little. The greater cost of cleaning up Microsoft software reflects the widespread use of it by relatively clueless lusrs. But this widespread use means that "total cost" gets spread across a bunch more people. Was the disruption disproportionate to the laxity that Windows sys admins and Microsoft programmers had showed immediately prior to this incident? No, it was a bargain. And trust me, the cost of Code Red cleanup is a bigger bargain if it means that people will wake up to the importance of security in the future.

Right now in the wake of the dot-com collapse, an outbreak of Code Red means we can't get our email for a day or something. But when we are truly dependent on the net in the future it is imperative that we are ready and history shows us that we would not be without a few swift kicks in the pants like this. As I mentioned in another post, I don't think Richard Smith is sophisticated enough to be a leader on issues like this.

Re:Sometimes you need to bring out the sledghammer

[TephX]

I've always been a firm believer against virus-watchers who release full exploits to the general public. It simply isn't necessary. The same results (warning Microsoft) could have been done without causing such a hyped panic.

If the only action taken is to warn Microsoft, someone will discover the problem elsewhere, eventually. In the meantime, Microsoft is unlikely to take the complaint seriously - after all, the damage is only "theoretical", right? Now, it's a fact that there are a lot of inattentive, lazy sysadmins out there, many of whom are running IIS, and that's why they haven't all applied the patch yet - but at least with this in the news, it's harder for them to avoid it. How many would bother to apply the patch if there weren't any obvious benefit to doing so? Many might choose not to disturb a working installation.

Personally, I think that the only software that can ever hope to be secure in the real world is built like a tank. Use a language or library that makes it impossible to have buffer overflows; assign permissions to everything and never give out more than you need to; etc. But in an environment where exploits are only theoretical and only announced to the entity responsible for fixing them, you have to admit that companies like Microsoft will be very slow to fix them.

This is absurd

[schon]

Why is slashdot giving wind to this troll?

This guy is woefully misinformed, and completely stupid.

Anyone who is subscribed to Bugtraq knows that eEye has already responded to him, and the bottom line is that Code Red is not based (in any small part) on the eEye security bulletin.

This proves that the guy is completely wrong.. because Code Red wasn't based on the eEye bulletin, that means that the "black hats" already knew about the vulnerability.

Like scientists, security professionals rely on an existing body of work. If the only people who had access to this body was the vendors, it would slow down the white hats, making the entire situation worse, not better.

Please do not feed this troll.

Re:Sometimes you need to bring out the sledghammer

[TheCabal]

...instead of a tap on the shoulder. Some companies need some "convincing" to make the necessary changes in a timely manner. Microsoft is definitely one those companies.

Unrepentant bullshit. Microsoft is very good at getting fixes out. Some bug-hunters expect a 2 hour turnaround time on their reports before "forcing MS to fix this by going public". Eeye even says that MS was quick in putting out a patch to fix the hole. The vast majority of bug hunters that actually take the time to work WITH Microsoft say that MS is quick in getting patches developed and in the hands of administrators, where they aren't applied (but that's a different story). Where's the sledgehammer? Can you support your claim with any evidence of any kind, or is this merely Yet Another Case of Uninformed Microsoft Bashing?

What?

[quartz]

I thought the patch was already available when Code Red started spreading. Sorry, but whyle delaying the full disclosure can slow down the virus writers a little, it's not going to make lazy sysadmins apply patches to their servers any faster.

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.

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).

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.

My problem with this.

[tycage]

My only problem with this is that Microsoft lacks the motivation to fix the hole if no one else knows what it is.

Sure, people can point out there "some hole" exists. But unless the details are made public, Microsoft (or whoever)isn't motivated to fix it, and no one can check up after them to see if it has been fixed. We have to take their word for it. That would make me very nervous.

I wouldn't be against a "grace period" where the vendor is told of the hole so that a patch can be ready when it is announced, but it would need a time limit on it to keep it from being delayed forever.

--Ty

Re:My problem with this.

[dudle]

My only problem with this is that Microsoft lacks the motivation to fix the hole if no one else knows what it is.

I don't generally defend MS but what you said is simply not true. If you compare MS to other companies, I think they have a descent response time and take ALL issues quite seriously. Yes their product sucks but as far as I know (and I read Bugtraq religiously), they are usually not too far behind.

The first one who replies to my post by mentionning Code Red doesn't know what he is talking about. MS released a patch for Code Red weeks before the worm spread like wild fire. Get your story straight.

Every now and then there is this discussion on bugtraq about full disclosure. It started last week by someone mentionning the cost of the worm and its variants. How eEye could have done better and stuff

Let me make myself clear: Full disclosure is mandatory!. Without it, we are all screwed.

Please flame accordingly.

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.

Full disclosure is the solution not the problem...

[twivel]

First of all... Full disclosure did not facilitate the creation of this worm. It was based off of a previous worm that was available long before the details of the exploit for Code Red was made available. This particular worm did not use the research form eEye's exploit, it's obvious from the way this worm exploits the vulnerability.

Vendors all around view a vulnerability that has been publically exposed as a much higher priority than those that have not been exposed. Over and over again, history has shown that a vendor will try to cover up a vulnerability if it is not exposed, to avoid bad publicity. (No, this is not specific to Microsoft, all vendors hate bad publicity). If an exploit is publically available for a particular vulnerability, it also changes the method in which the vendor advertises the patch, thus increasing the people who know about it and install the patch.

Full disclosure provides many useful functions, including the ability to test for vulnerabilities in their own systems. It gives them the abliity to verify that the system has been properly secured after a work-around has been implemented.

Partial disclosure, which is often suggested, is no different htan full disclosure, except it may give the admins a false sense of security. With partial disclosure, the existence of a bug is disclosed to the public - but the details are not. Sad enough, once the cat is out of the bag, it's only a day or two before someone else can figure out the exploit. Once the vendor releases a patch, it is trivial to do binary diffs on the provided updates and figure out the details of creating the exploit. In fact there are tools that help to automate this already in existence today.

The sad thing about code red is this: Patches have been available for quit a while now. Yet systems are still getting hit. The widespread affect of Code Red is the ONLY thing that will get the admins who never patch their systems to potentially pay attention to whats going on.

Full Disclosure is not the problem. If one person has found the vulnerabilities, there are generally more who have found them and are actively exploiting it already. To think otherwise is to seriously underestimate the cracker community.

--
Twivel

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.

Re:Sometimes you need to bring out the sledghammer

[ChadAmberg]

I'm sorry, but I would really prefer to have the information that a certain lock installed on my frontdoor can be picked just by staring at it really hard, so I can go out and fix it or replace it.
If all I had to go one was "somethings wrong with the door" what the hell are we supposed to do about it?
Sure other criminals might now about it now. But I've already fixed the problem, or I have a contingency shotgun in place, etc.

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:Sometimes you need to bring out the sledghammer

[Hammer]

While I hate MicroShaft (ask anyone at my job) and TheCabal appears to have a slight slant towards BillCo, I must reply to this!

1. They are pretty good at putting out fixes (if more than a little low key on the announcement thereof)
   
2. This kind of childish personal attacks only gets back at you and unfortunately all of us. (I think you know that using AC to post)
   
3. They certainly deserve a good bashing from time to time. However, please keep the bashing based on real facts, not generic BS. (we like to bash them for their FUD, let's not spread FUD ourselves)
   

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.