[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <871080DEC5874D41B4E3AFC5C400611E06B4761D@UTDEVS02.campus.ad.utdallas.edu>
From: pauls at utdallas.edu (Schmehl, Paul L)
Subject: DCOM RPC exploit (dcom.c)
> -----Original Message-----
> From: Robert Wesley McGrew [mailto:rwm8@....MsState.EDU]
> Sent: Monday, July 28, 2003 3:01 AM
> To: full-disclosure@...ts.netsys.com
> Subject: Re: [Full-Disclosure] DCOM RPC exploit (dcom.c)
>
> 1) How would you propose to change the
> scene/industry/community of security in such a way that would
> prevent the public release of exploit code like this?
>
I don't think you *can* change it. People are going to release exploit
code. It's that simple. I *do* think we have to find a way to pressure
vendors into doing a better job of auditing their code and
out-of-the-box configurations (Microsoft being the absolute worst at
both), but I'm not convinced lawsuits are the answer. As has been
pointed out, that could work to the commercial vendors' advantage and
kill open source development.
> 2) For this DCOM RPC problem in particular, everyone's
> talking about worms. How would the worm know what return
> address to use? Remote OS fingerprinting would mean it would
> be relatively large, slow, and unreliable (compared with
> Slammer), and sticking with one would cause more machines to
> just crash than to spread the worm. I haven't looked into
> this very closely yet to see if it can be generalized.
What fingerprinting? If you've got 135/UDP open to the Internet, you're
screwed. Slammer didn't fingerprint. It simply hit every box it could
find on port 1434/UDP, and the exploit either worked or it didn't. Most
worms do the same. They attack indiscriminately, and infect those Oses
that are susceptible. And with Windows, that's enough boxes to cause a
real problem.
Paul Schmehl (pauls@...allas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/~pauls/
Powered by blists - more mailing lists