> -----Original Message----- > From: Robert Wesley McGrew [mailto:[EMAIL PROTECTED] > Sent: Monday, July 28, 2003 3:01 AM > To: [EMAIL PROTECTED] > 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 ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/~pauls/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
