The DCOM security functionality is similar to CORBA in ability although they look substantially different from a development standpoint. DCOM has seven security levels that provide various degress of authentication, integrity and confidentiality.
Level One - No authentication Level Two - Connection authentication. Level Three - Default authentication (currently the same as level two) Level Four - Call-level authentication (authenticates all method calls in an object) Level Five - Packet-level authentication (authenticates each packet in a transmission) Level Six - Packet integrity-level authentication (same as five with packet checksums added) Level Seven - Packet privacy-level authentication (encrypts all data) As it is with most security, the DCOM authentication level you use depends on the application and its associated risks. Up through level four hijacking attacks are possible, levels 5 is susceptible to man-in-the-middle attacks, level 6 data can still be captured and read and level seven may be suspectible to brute force attacks if the underlying encryption is poor. DCOM has some other security measures that limit the ability of the server objects to act on behalf of the client (a.k.a. impersonation). For example, the default mode only allows the server (remote system) to get identify information from the client. The impersonation level allow the server to act on behalf of the client but the server cannot pass the client request on to other servers or grant them authority to act on behalf of the client. These are the only two level available to developers but there are two additional levels defined. The anonymous level prevents servers from getting authentication information from clients and the delegate level allows servers to delegate the client authority it has received to other servers so they can act on behalf of the client. The only other security issue that I've come across has to do with COM objects is related to memory reuse. One application I reviewed had problems with buffers being overwritten during data transfers. This occassionally resulted in data from one customer being exposed to another customer. The company added a data integrity check to prevent the wrongful exposure but they were still trying to resolve the buffer overwrite problem where I left. -- Bill Stackpole, CISSP ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, April 15, 2002 9:06 AM Subject: RE: risks and threats with DCOM ? > Thanks a lot! > > So it is possible to restrict the communication to a single TCP or UDP port. > > The white paper says nothing about authentication and encryption features. Is there a way to have confidentiality and authenticity of the data? > > The remaining issue is: > > in "normal" protocols like http, smtp, DNS etc there is a transmission of *data* > DCOM is transmitting data *and* function calls on application layer. > > So common firewalls are not able to control what the end points of the DCOM communication are doing. Aren't they? > Is there a kind of plug in or proxy to control the content like the Checkpoint is doing for ftp per example with inspection code? > > I know a product which is doing this for IIOP but not for DCOM. > There is also a proxy functionality available. > > Erik > > > > > > -----Original Message----- > > From: John Allhiser [mailto:[EMAIL PROTECTED]] > > Sent: Monday, April 15, 2002 4:27 PM > > To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] > > Subject: RE: risks and threats with DCOM ? > > > > > > Erik, > > > > Try this link. This MS' whitepaper on the subject. > > > > http://www.microsoft.com/com/wpaper/dcomfw.asp > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Monday, April 15, 2002 4:27 AM > > To: [EMAIL PROTECTED] > > Subject: risks and threats with DCOM ? > > > > > > Dear all, > > > > What are the risks and threats of the DCOM protocol when > > using it across > > firewall boundaries? > > > > I just know that it is similar to the "CORBA" communication > > model (M$ version). > > (?) > > > > CORBA IIOP is a communication model at layer 7 - within an > > application. > > Two systems using CORBA may run a distributed software where > > pieces of the > > software on each system uses CORBA communication to send data > > *AND* function > > calls across the network. > > This represents a kind of virtual computer. > > Putting a Firewall between pieces of a network distributed > > virtual computer > > makes no sense, right? Exept concerning filtering of IP adresses... > > > > Is anybody familar with the security issues and features of > > the DCOM protocol? > > Any hints for further documentation? > > What are your opinions about this? > > > > thanks in advance > > regards > > > > Erik > > _______________________________________________ > > Firewalls mailing list > > [EMAIL PROTECTED] > > http://lists.gnac.net/mailman/listinfo/firewalls > > > _______________________________________________ > Firewalls mailing list > [EMAIL PROTECTED] > http://lists.gnac.net/mailman/listinfo/firewalls _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
