-----BEGIN PGP SIGNED MESSAGE-----

>The first paragraph mentioning Code Red, along with the second
>paragraph, implies that eEye did *not* disclose to the vendor
>Microsoft before
>releasing technical details, which is false. It does not mention
>that the worm was an older worm with a more advanced buffer overflow
>technique than what eEye came up with, and that this new buffer
>overflow was simply grafted into an older worm. Instead by using
>carefully chosen words and sentences, with a mix of facts and
>omissions, you have demonized eEye. Was that intentional or
>coincidental?

I never said that, and I've been quoted as saying just the opposite,
that eEye did work with MS for a month prior to the patch release,
and that they released their advisory after the patch was released. I
can't speak to the motivations of the write of this piece, but can
only say that it wasn't me.

>eEye *did* act responsibly. They worked with Microsoft and in a
>coordinated effort, released their information at the same time.

In some ways they did act responsibly, in others they didn't. In a
post to Bugtraq Marc says;

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

and

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

and finally;

"This isn't the 70's. People are easily able to write exploits simply
from the data that Microsoft gives within their advisories."

Despite these statements, eEye still felt compelled to provide
technical details of how to exploit the overflow in their advisory.
Was this the first time they were put to shame by some other
programmer? According to Maiffret's implications, probably not. So
why did they ever think to include them? Only to have the public see
how poorly they can construct exploits?

I think not. eEye is a company, and each of their advisories contain
information about their products...products they are quick to remind
us will protect you from unknown exploits. Whether they as
individuals agree or not, their investors believe its effective to
show how vulnerable someone is to their discoveries in the hopes they
will buy their products/services. They're not alone, I do it to, we
just do it in different ways.

They're advisory served to provide information to the security
community, and IDS/Scanner vendors, but also to provide marketing
impetus to their products. Part of that effort was to show how they
were smart enough to develop what they believed to be a difficult
overflow into a "useful exploit". Whether the details of this
provided the basis for Code Red can't be determined unless we ask the
author(s). Did the Code Red author(s) investigate how IDQ.DLL could
be exploited using the details provided by eEye? Did they save an
hour making the .htr worm work against IDQ.DLL due to the information
eEye provided? Who knows. eEye certainly doesn't, despite their
claims to the contrary.

Were those details required to better assist IDS and Scanner vendors?
Well, according to Maiffret that's totally unnecessary, "this isn't
the 70's" don't we know. Are they suggesting that IDS/Scanner vendors
don't disassemble patches produced by Microsoft and so are dependent
on eEye's analysis? So if not for the IDS/Scanner Vendors, then the
details must have been for the Administrators who want to code up
their own protections for what eEye discovers, right? I think not,
that would be contrary to selling products which do that protection
for you, something eEye does.

Did those details, and the demonstration of how the overflow could be
exploited, get people to patch their systems? Nope, hardly at all. So
is this practice of Full Disclosure effective? Nope, not at all.

However, what does seem to be effective is to give full details about
security vulnerabilities such that anyone can create a worm, or
attack, or script and actually start attacking systems. This seems to
be fairly effective at getting people to do something fairly quickly.
What they do isn't important it would seem, that they respond, and
provide good readership to media articles and web page descriptions
of the problems is all that matters.

Notice how it makes no difference how many times such attacks have
occurred, a sufficiently large enough group of people haven't heeded
the warnings and are vulnerable. That's all anyone's after, it would
seem.

A marketing person might look at this sequence and see a viable
business model.

In the end, it is the attack or exploit that causes people to patch,
not the advisory of the vulnerability. Yet its pretty clear that
until the advisory of the vulnerability is published, the attack
rarely rears its head against a large segment of the Internet.

Simple Nomad makes the suggestion that push mechanisms for patches
might be needed. In fact this is being actively discussed as a viable
and needed method. But what then will you do to make such a media
impact as eEye did when they announced their .ida vulnerability? The
media could care less if nobody is at risk, and if push mechanisms
are used to protect everyone prior to disclosure...well, it just
won't make for a good story any more.

So in such a world, what do security product vendors sell you then?
You think that Full Disclosure won't go the way of the Dodo in such a
world? You think everyone will want to work so hard to give MS
information that will give them no marketing collateral? Or, do you
think, they'll keep the information to themselves and use it to show
how systems are vulnerable and why their new widget will protect
them?

>It does not address that Microsoft has repeatedly added new features
>that are on by default without telling anyone, which is evident when
>half of the workarounds for IIS problems involve turning off a
>default setting that less than 1% of their user base might ever use,
>let alone even heard of.

And your figures are based on what? Your experience? Sorry, but I
have to believe even you would admit that you haven't ever talked to
or looked at 1% of their user base. Which product is it that doesn't
turn on things by default that most users need? How widely adopted is
it, and have you ever asked yourself why?

>Let us not forget the entire RDS episode, when you were using this
>"inside information" to get clients, only to have a clever hacker
>develop an exploit based upon the limited technical knowledge you
>divulged publicly.

WHAT!!! I had no clients when RDS was being discussed. I used no
"inside information" to get clients. Mind sharing what you think you
know here rather than just trying to assert a falsehood?

Many people asked to have run against them. For the most part I
simply had them look in the registry to see if the keys were there,
asked if they needed RDS, and if they didn't, had them remove the
keys. I explained why they were vulnerable and didn't have to run the
tool at all. For those that didn't believe me I demonstrated while
they were on the phone with me.

The tool wasn't written by me, or for me, nor did I benefit
financially from it at all.

>In all seriousness, do you *really* believe what you are saying when
>it comes to full disclosure, or is this a ploy to get press?

I certainly believe what I'm saying. I'm not sure whether I believe
what *you think* I'm saying.

>But you will never ever get rid of full disclosure at this point.
>Period.

Anyone with any sense will realize that Full Disclosure has to be
practiced for Responsible Disclosure to exist. You can't have one
without the other. Duh!

Full Disclosure has far too many definitions, myths, beliefs, and
other connotations for it to be promoted effectively. It means
whatever anyone wants it to mean, so it can be a mantra for good and
evil just as easily. Its respect is given in context, not blindly for
the term.

Responsible Disclosure is an attempt to focus attention on providing
a definition that is promotable. Education must continue, research
must be done, details must be disclosed, and the public must become
aware of issues. No arguments with any of these points, the only
question is HOW?

30 years of Full Disclosure hasn't changed how Unix or MS programmers
write code. All of that Full Disclosure still has us facing 10-20
messages a day discussing new vulnerabilities. Where's the progress?
There are lots of serious efforts afoot to change all of this, as
there have been for 30 years, in the meantime the general public
(hundreds of millions of them) want to see something done now to
protect them.

Nothing that you've suggested, or that I've seen suggested anywhere,
is going to do that in a timeframe that meets the public's
expectations. What do you say, just tell them not to connect? Tell
them all to get Linux, or OpenBSD? Tell them all to buy a Firewall,
or cook one up for themselves? For better or worse that's not what
they want. You can continue to keep your head in the sand and call
for ages old changes, or you can get with the program and see if
there aren't alternatives.

Responsible Disclosure is just one alternative. Not something that
solves all problems or removes all evil, simply a position from which
I believe progress may be made.

eEye isn't the villain, nor are they to blame, but even they realize
that sometimes they have more information than the general public
needs. Virtually all disclosers have come to that realization at some
point or another, and they haven't acted consistently even from one
vulnerability to the next. This suggests that they are practicing
Responsible Disclosure, but they're changing the lines in the sand to
accommodate the individual situation. Defining something that would
provide them with more consistency can only benefit everyone. You'll
never stop people from disclosing all of the details, but you can
encourage them to do so with a conscience and some forethought. To
aide them in that decision, you provide a large group of people who
can assist with opinion and alternative views. This all happens now,
the only difference is the size of the group who share in the "inside
dope" and who's opinion you respect. Every discoverer eventually
tells someone other than their own small group, so why not set
something up to make that more possible for more people?

eEye shared their information with Microsoft. They may have shared it
with others outside of eEye prior to sharing it with Microsoft. Each
step of the way they spoke their opinion, and others offered theirs.
The culmination of that was their .IDA advisory.

Had a Responsible Disclosure Forum been around it may have happened
that the eEye advisory might have looked differently. It may not
have, but it might. Were it not for the competitive nature of
vulnerability disclosures, say had the work been done in a University
instead of a company, the publication would have been very different.
In the research world peer review is a crucial action prior to
publication. Why then isn't it acceptable when it comes to computer
security? To suggest that publication on Bugtraq is peer-review would
be incorrect. There's no respect given to others work on Bugtraq,
people will steal anything they find useful and use if for whatever
purpose they choose. There's a need for credibility amongst
researchers in most other fields that prevents such mis-use of
information, but no such ethic or need exists amongst computer users.
A need must then be created, and a method found to promote it. With
its promotion comes a desire to be part of it, which eventually leads
to its regular practice and methods of enforcing it.

Its all in a world far away, in a time some point in the future, but
its well worth working towards rather than fumbling around in the
present using out-dated approaches to ages old problems. Do you tell
your children not to bother being polite because half of the people
they meet won't be polite back to them?

>BTW, do you know who has your complete and full support? People who
>break into computer systems that hate the script kiddies who abuse
>their
>privately-held exploits. They have an argument that full disclosure
>hurts the underground community. Check out http://anti.security.is/
>for an idea of what I am talking about. My guess is they love you.

Hahaha...;-]

Honestly, do you believe that any attack will be around long, if
applied widely? That 100, or 1000 computers are surreptitiously
attacked by an unpublished vulnerability is terrible. That 100's of
thousands of machines are sacrificed so 100 or 1000 can be saved is
abhorrent.

Far too little consideration is given to the larger effects, and far
too many naive people believe that everyone's paying attention to
their advisories. The security world is maybe populated by 100,000
people who pay attention. The rest don't have time, or don't
understand, or don't know.

Its time for a change.

Cheers,
Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.2

iQCVAwUBO3gfjxBh2Kw/l7p5AQFFewQAhZABTUEQYU8D8SSIssgaGQdlnqS9Ew0m
xCQe3EeDvWrLS1RU3dcGD0Otes9U5ienvoGdaG3O1Oikozf51O6Clzfte7pMT+rl
s2FrQVbfhFTMhhSbKWbLeROhD9v3sBnB/zFhewX6X/Il6wNehkTknSRJUWQ9oq91
v0T+pSV/HUk=
=/bRo
-----END PGP SIGNATURE-----

============================================================================
Delivery co-sponsored by Trend Micro, Inc.
============================================================================
TREND MICRO SCANMAIL FOR EXCHANGE 2000 -- SECOND to NONE

If you are worried about email viruses, you need Trend Micro ScanMail for
Exchange. ScanMail is the first antivirus solution that seamlessly
integrates with the Microsoft Exchange 2000 virus-scanning API 2.0. ScanMail
ensures 100% inbound and outbound email virus scanning and provides remote
software management. Download a FREE 30-day trial copy of ScanMail and find
out why it is the best:
http://www.antivirus.com/banners/tracking.asp?si=8&BI;=240&UL;=/smex2000
============================================================================

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]