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

9 of 269 comments (clear)

  1. Sex Education by lcypher · · Score: 5, Insightful

    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.

  2. This is absurd by schon · · Score: 5, Insightful

    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.

  3. What? by quartz · · Score: 4, Insightful

    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.

  4. More info by GeorgeH · · Score: 5, Informative

    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"?
  5. My problem with this. by tycage · · Score: 4, Insightful

    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

    1. Re:My problem with this. by dudle · · Score: 4, Insightful
      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.

      --
      Looking for a great online backup: Green Backup
    2. Re:My problem with this. by WNight · · Score: 4, Informative

      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.

  6. Full disclosure is the solution not the problem... by twivel · · Score: 5, Insightful
    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

  7. Past history can tell by jsse · · Score: 5, Informative

    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.