Full Disclosure mailing list archives
Re: DCOM RPC exploit (dcom.c)
From: Nick FitzGerald <nick () virus-l demon co uk>
Date: Mon, 28 Jul 2003 12:33:56 +1200
Paul Schmehl <pauls () utdallas edu> wrote: <<snip>>
It takes a lot more work than that. What do you do about the machines that *do* need DCOM? Ever notice there are students learning programming at a university? It's not like a corporation where you can shove changes down people's throats without planning carefully first.
Well, I don't know why anybody ever let most of that MS networking stuff run over TCP/IP in the first place. True, preventing NT-based OSes from binding RPC and other less-desirable stuff to every available interface is not easy, but it is getting more do-able. In case you haven't looked yet: Minimizing Windows network services Jean-Baptiste Marchand http://www.hsc.fr/ressources/breves/min_srv_res_win.en.html.en Now, so long as you didn't scrimp on network infrastructure and build important parts around cheap, TCP/IP-only routers, take that information and start thinking "what if we put Windows RPC services on IPX/SPX?". Still doesn't help you prevent the morons who are allowed to install/config their own boxes from "getting it wrong" but gives that part of the network that does accept your guidance a fair degree of "free" protection while leaving DCOM RPC avalable to those that really do "need" it.
You have consistently stated that all that needs to be done is "the work". The implication is that there's nothing to it. It can be easily done if folks would just get to work. That implication is false and trivializes the amount of work that has to be done. That is what I'm objecting to.
I'd also object most strongly that MS still sees fit to decide a priori that a _very little used_ service "should be" installed and enabled and bound to every firking network interface on every box its OS is installed upon. We kept hearing that "least privilege" and "service minimization" were the key drivers behind the Windows Server 2003 security review -- we now know that the drivers were DWI... But it gets worse. Instead of being off by default and requiring a degree of nouse be applied in the very rare cases where those services really are needed, we have something that requires intimate familiarity with your hardware and arcane registry tweaking procedures to remove to make your machine "well-enough secured". (And what's the bet that the interface-by-interface binding of RPC services described in Marchand's paper can (silently) "break" if you add, remove or reconfigure network adaptors in the machine??) Regards, Nick FitzGerald _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- Re: DCOM RPC exploit (dcom.c), (continued)
- Re: DCOM RPC exploit (dcom.c) Nick FitzGerald (Jul 26)
- RE : DCOM RPC exploit (dcom.c) Nicolas Villatte (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Jason (Jul 26)
- Re: DCOM RPC exploit (dcom.c) Chris Paget (Jul 26)
- Re: DCOM RPC exploit (dcom.c) Jason (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Paul Schmehl (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Jason (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Paul Schmehl (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Jason (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Paul Schmehl (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Nick FitzGerald (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Jason (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Paul Schmehl (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Ron DuFresne (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Jason (Jul 28)
- Re: DCOM RPC exploit (dcom.c) Robert Wesley McGrew (Jul 28)
- Re: DCOM RPC exploit (dcom.c) Robert Wesley McGrew (Jul 28)
- Re: DCOM RPC exploit (dcom.c) Ron DuFresne (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Paul Schmehl (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Knud Erik Højgaard (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Paul Schmehl (Jul 27)