> From: Rain Forest Puppy [mailto:rfpVULNWATCH.ORG]

> Face it: the people you need to worry about will have this
> information one
> way or another, whether it be propogated in IRC, amongst
> closed groups,
> figured out for themselves, or off some other forum. All
> you're doing is
> naively delaying the inevitable, and keeping many people in the dark.

I'm not entirely sure that statement always holds up. Let's step back and
look at how these things have gone historically. I see all sorts of
vulnerabilities come through Microsoft. Not all of the ones that are serious
vulnerabilities become a widespread menace. Now, in the spirit of scientific
inquiry, let's think about what characteristics distinguish a serious
vulnerability that isn't widely exploited from one that is.

First let's note that the UNIX community and reactions to vulns seems to
behave differently. I'm not entirely sure why that is, but Mudge pointed it
out to me while we were discussing this at USENIX this last week. Point is
that population behavior is different. Perhaps the UNIX script kiddies and
the Windows script kiddiez are different populations.

One obvious distinguishing factor is that the vulnerability needs to affect
a large portion of the target population. A really nasty exploit that only
works against 1 in 100 systems doesn't seem to become popular. Another
distingishing factor seems to be the release of user-friendly exploit code.
A serious vulnerability where user-friendly exploit code isn't released
seems less likely to be widely exploited. Like anything involving people,
exceptions do exist, but the trend seems to be there. It's worth thinking
about - I think there are factors other than chance that explain the
difference in serious vulns that are widely exploited and serious vulns that
are not widely exploited.

> Quick show of hands...who finds these types of things useful?
> Who used a
> Code Red scanner before Microsoft came out with theirs (which
> isn't really
> the same thing, but still)?

I didn't distribute our Code Red scanner. It's just a tool to clean up the
mess the worm leaves. I hope people who use it seriously read the warnings
on the web page. The tool can clean up the worm, but it can't clean up the
hacker who showed up before or after the worm.

BTW, I posted a new rev with some bug fixes yesterday.

> Now, how the hell would these types of scanners be possible
> if the full
> information wasn't published? So who loses in that situation
> (hint: not
> the bad guys, they have the information anyways)?

Actually, the full information about the vuln itself was COMPLETELY USELESS
to me when I created the module that scans for vulnerable systems. The
observation that the full path is returned by a vulnerable DLL, and it is
not returned by the fixed DLL (posted to BUGTRAQ by Chris St. Clair). I had
full access to the details of the problem, access to the source code that
caused the problem, AND had a working exploit, but I didn't use any of that
to create my scanning tool.

The issue here is that a scanning tool needs only to distinguish a
vulnerable system from one that is not. It isn't always required to actually
execute the exploit. Exploit code is notoriously unreliable, and often
misses certain platforms or service pack revisions.

The same thing also happened for the .printer overflow. Full details about
the vuln were also completely useless when I wrote the check module.

A counterpoint is that you do have to actually exploit the MDAC bug to test
for it.

<snip>
> same principle of logic, I should then just assume you're stupid.

I don't think flaming helps the discussion.

> There's two factors at play: responsibility of the vendor to
> keep the crap
> secure in the first place, and responsibility of the admin to keep the
> crap up to date when it's not secure. Those are the
> problems. How the
> insecurity arises is not.

I disagree. There are more factors at play than that.

> If people patch, then none of this matters. If the vendors
> make secure
> stuff, then none of this matters. But not releasing details
> STILL DOES
> NOT CHANGE THE FACT THAT PEOPLE ARE INSECURE.

I can agree with this, but sometimes I go off and leave my front door
unlocked. I'm definately insecure when that happens. If people had unlocked
front door scanners that could find my unlocked front door from miles away,
it would change the threat scenario.

There's also the fact that it takes time to patch systems. If I can get
started patching before millions of script kiddies start attacking me, I
stand less chance of getting hacked. There is benefit to increasing the time
between patch availability and widespread attacks.

> ------ IMPORTANT MORAL -- IMPORTANT MORAL -- IMPORTANT MORAL ------

> What you're doing, Russ, is pushing to make it acceptable to
> be vulnerable
> as long as you're not being actively exploited. That is absolutely
> *wrong* and *naive*. Explotation or no explotation, the Internet will
> still have a festering pool of ripe vulnerability.
>
> The fundamental problem is not removal of the exploitation--it's the
> removal of the vulnerability.
>
> ------ IMPORTANT MORAL -- IMPORTANT MORAL -- IMPORTANT MORAL ------

I don't know if I'd say that is the way I interpret Russ' position, but it
isn't acceptable to leave your system vulnerable. IMNSHO.

There are a number of fundamental problems here, and focussing on only one
of them is less productive than working on all of them. None of them have
easy fixes, and none of them are likely to work 100%.

The first fundamental problem is that of incorrect design from a security
standpoint. We must work to improve design from a security standpoint, and
reduce the attack surface.

The second fundamental problem is that of secure implementation. Programmers
need to be better educated. There are starting to be books available on
this - Michael Howard and I have one coming out later this year. Another
aspect of this problem is that we all need better tools to check source for
potential problems. We also need better tools to test finished products for
problems - Greg Hoglund's Hailstorm app does some interesting things in this
area.

The third fundamental problem is that of getting fixes created in a timely
manner, and notifying the customer that these fixes are available.

The fourth fundamental problem is getting the fixes actually applied to the
system, including determining which systems require the patch.

In addition to the above, we also have the problem of people who think it is
acceptable to not disclose exploits to vendors, and we have the problem of
how you can get things fixed and get things patched without having armies of
script kiddies creating mayhem while we do it.

We clearly have a lot of hard problems to solve.

> (topic: RDS)

> Oh, I see. This must have been a private tool developed my Microsoft,
> since they're the only ones that should have that info,
> right? How come
> we didn't get to use this private tool, so that all our
> clients who needed
> to see it demonstrated would be convinced to patch?

Um, this is a REALLY bad example. I agree with your point, but this example
doesn't make it very well. First of all, the first available exploit tool
was written by someone outside of Microsoft, and that's what Russ had.
Secondly, the RDS exploit is actually FULLY DOCUMENTED in various SDKs.

> But seriously, you realize Russ your entire argument is worth
> piss as soon
> as someone clever and willing to make a point codes a worm
> that uses an
> unpublished vulnerability as a propogation method. I'm not a
> bettin' man,
> but I guessing we'll start seeing these baddies within three
> months, tops.

And I've seen extremely serious vulnerabilities that got fixed, bulletins
got created, and worms weren't written and script kiddiez didn't create
mayhem. We're dealing with a complex system here based on human behavior.
One example won't prove or refute any theory substantial enough to not fit
into a nutshell.

David LeBlanc
dleblancmindspring.com

_____________________________________________________________________
** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice"
** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST"
SEND ALL COMMANDS TO: listservlistserv.ntsecurity.net

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