From:	 "Marc Maiffret" <marc@eeye.com>
To:	 "Richard M. Smith" <rms@privacyfoundation.org>,
	 "BUGTRAQ@SECURITYFOCUS. COM" <BUGTRAQ@SECURITYFOCUS.COM>
Subject: RE: Can we afford full disclosure of security holes?
Date:	 Fri, 10 Aug 2001 13:10:51 -0700

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