Re: Anyone know much about DCOM?

[Ted Doty <ted () iss net>]

At 11:00 AM 6/17/98 -0400, Don Kendrick wrote:
> Greetings,
>
> I'm being rushed into a project that will involve putting a component on my
> NT web server that will talk to various MS boxes internally. They are
> proposing to use DCOM. A quick look at DCOM shows me that they are basically
> doing RPC stuff and of course I'm not a real fan of RPC.

This probably deserves to have a book written on it (by someone other than
myself).

Last time I checked about DCOM, there were several issues that would make
me a little hesitant to use DCOM over public networks, for several reasons:

1. As you pointed out, DCOM uses MSRPC.  RPC is pretty complicated; it's
also pretty new.  This suggests that it's not well understood in general.
MSRPC can use a host of transports: names pipes, TCP, and Netbios over TCP.
 Given that all the default services that ship in NT use named pipes, and
that named pipes use SMB, you have to open port 139 to allow your DCOM
stuff in from your web server.  Having 139 open allows access in to a
number of services (like file and print, for example).

If you really want to do this, it's a good idea to specify TCP as the
transport and only punch holes in the firewall for specific services that
are needed.  Also, it's better (from a security point of view) if the
developer specified static endpoints on the server - this way the client
doesn't need to connect to port 135.  However, if the developer wasn't
security-aware, you may be stuck with dynamic endpoints.  In this case,
your server's exposure will be much worse, and your firewall administrator
will find herself living in interesting times.

2. MSRPC currently only supports NTLM authentication, which is neither
amazingly strong or amazingly flexible.  Make sure that both client and
server are running NT 4.0 Service pack 3: that way if you have to use named
pipes you can use the SMB message signing feature for integrity checking.
Again, if you want to use TCP for transport, the developer has to have
added support for fully encrypted RPC, or your sessions will be vulnerable
to insertion or hijacking attacks.

Overall, NT 5.0 is likely to be a win.  Kerberos supports mutual
authentication and proxying of user credentials.  You may be better off
stalling installation until 5.0 is out.

3. Don't have any hard evidence of this, but there's reason to suspect that
interesting RPC packets might cause Blue Screen Of Death.  Opening up too
much through the firewall can potentially provide an avenue for DoS attacks.

Note that these are my opinion's not my employer's, and I might be nuts anyway.

- Ted

-----------------------------------------------------------------------
Ted Doty, Internet Security Systems          | Phone: +1 678 443-6000
6600 Peachtree Dunwoody Road, 300 Embassy Row | Fax:   +1 678 443-6479
Atlanta, GA 30328  USA                       | Web: http://www.iss.net
-----------------------------------------------------------------------
PGP key fingerprint: 362A EAC7 9E08 1689  FD0F E625 D525 E1BE