RE: Can we afford full disclosure of security holes?

From: Marc Maiffret (marcat_private)
Date: Fri Aug 10 2001 - 13:10:51 PDT

  • Next message: Bill Arbaugh: "Re: Can we afford full disclosure of security holes?"

    After about 3 weeks of little to no sleep and spending lots of my (and Ryan
    Permeh's) personal time researching CodeRed and its many variants I have
    grown tired of the small number of people who so ignorantly have pointed a
    finger at eEye and are trying to somehow get people to think that we are
    responsible. As an employee of a company I must hold back some of my
    feelings... however as an individual I can tell you that this is all
    complete and utter crap.
    
    |Hello,
    |
    <snip>
    |This $20 million figure begs the question was it really
    |necessary for eEye Digital Security to release full details
    |of the IIS buffer overflow that made the Code Red I and II worms
    |possible?  I think the answer is clearly no.
    
    Where the hell do you or anyone get off by saying that eEye's advisory made
    CodeRed possible? This sort of ignorance being spread in a public forum is
    just one of the many things wrong with the security industry. Your making
    claims that you have no data to back other than "well I think so."
    
    |Wouldn't it have been much better for eEye to give the details
    |of the buffer overflow only to Microsoft?  They could have still
    |issued a security advisory saying that they found a problem in IIS
    |and where to get the  Microsoft patch.  I realized that a partial
    |disclosure policy isn't as sexy as a full disclosure policy, but
    |I believe that less revealing eEye advisory would have saved a lot
    |companies a lot of money and grief.
    
    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.
    
    So the facts are:
    Someone found an unknown buffer overflow vulnerability within the IIS .htr
    ISAPI filter, without any data from eEye.
    Someone exploited that unknown buffer overflow vulnerability in order to
    execute code on remote systems, without any data from eEye.
    Someone took that exploit even further and turned it into a worm (Which is
    what CodeRed is explicitly based off of) and launched it at the Internet,
    without any data from eEye.
    
    Now a few months later someone took that .htr worm and modified it to attack
    the .ida vulnerability. They already had ALL of the knowledge they needed in
    order to modify the .htr worm to be the .ida worm. There was nothing that
    eEye gave them that made it any easier.
    
    In fact when it comes down to it technically... eEye's technical exploit
    information within the .ida ISAPI overflow advisory was actually put to
    shame by a skilled programmer by the name of hsj. hsj published a working
    .ida ISAPI overflow exploit which used a wide character overflow technique
    which was far beyond (and nothing like) anything we talked about in our
    advisory. So technically the CodeRed worm and hsj .ida exploit were
    technically superior to anything that we (eEye) discussed in our .ida
    advisory. They did not use ANY technique that had anything to do with our
    advisory. If you, or any of the other small percentage of people pointing
    fingers at eEye, actually had any technical understanding of buffer overflow
    exploits then you might have understood that and not sent an eMail to a
    public mailing list making harsh accusations which are totally inaccurate
    and untrue.
    
    |Unlike the eEye advisory, the Microsoft advisory on the IIS
    |security hole shows the right balance.  It gives IIS customers
    |enough information about the buffer overflow without giving a recipe
    |to virus writers of how to exploit it.
    
    This isn't the 70's. People are easily able to write exploits simply from
    the data that Microsoft gives within their advisories. To say that hackers
    are not able to write exploits solely based off of a Microsoft Advisory is
    to underestimate the underground, which is a _bad_ thing to do. Most of the
    hackers we know have automated tools that allow them to compare the files
    held within a Microsoft security patch to system files that are being
    replaced and after running them through custom modules for IDA etc... they
    have pinpointed overflows etc... by ONLY using the information held within a
    Microsoft security bulletin and its patch.
    
    |Thanks,
    |Richard M. Smith
    |CTO, Privacy Foundation
    |http://www.privacyfoundation.org
    
    There is a big bad world out there far beyond the technical information seen
    on mailing lists like Bugtraq.
    
    Signed,
    Marc Maiffret
    Chief Hacking Officer
    eEye Digital Security
    T.949.349.9062
    F.949.349.9538
    http://eEye.com/Retina - Network Security Scanner
    http://eEye.com/Iris - Network Traffic Analyzer
    http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities
    



    This archive was generated by hypermail 2b30 : Fri Aug 10 2001 - 15:38:58 PDT