full-disclosure - DCOM RPC exploit (dcom.c)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.WNT.4.53.0307300930290.636@grizzly>
From: chris at ngssoftware.com (Chris Anley)
Subject: DCOM RPC exploit  (dcom.c)

On Tue, 29 Jul 2003, Schmehl, Paul L wrote:

> >Anyone else know what the last column of the output means?
> >i.e. '5.6' or '0.0'?

I've been playing with the underlying RPC calls a bit, which make me think
that maybe it's the 'COMVERSION' structure that's returned in the
'ServerVersion' parameter of the underlying
IRemoteActivation::RemoteActivation call.

Maybe this is a way to differentiate server versions? This will only
catch revisions to DCOM though. Not sure when they happened. Still,
maybe knowing the version of ORPC on the remote host is useful for other
reasons.

I don't seem to be getting very useful ServerVersion responses though.
There's an interesting fragment in the DCOM spec, relating to the
COMVERSION sent by the client in the ORPCTHIS parameter:

"The version number of the COM protocol used to make this particular ORPC.
The initial value will be 5.1. Each packet contains the sender's major and
minor ORPC version numbers. The client's and server's major versions must
be equal. Backward compatible changes in the protocol are indicated by
higher minor version numbers. Therefore, a server's minor version must be
greater than or equal to the client's. However, if the server's minor
version exceeds the client's minor version, it must return the client's
minor version and restrict its use of the protocol to the minor version
specified by the client. A protocol version mismatch causes the
RPC_E_VERSION_MISMATCH ORPC fault to be returned."

So maybe we can try major versions and then creep up the minor versions
until failure to get the true remote COM version, if ServerVersion is
unreliable.

There's probably not much point in doing this though, since folks seem
happy to just use offsets that work across most nt, 2k and xp sp's.

If anyone's interested in looking at the underlying RPC stuff, here are
some good places to start:

http://www.grimes.demon.co.uk/DCOM/DCOMSpec.htm
http://www.microsoft.com/msj/0398/dcom.aspx
http://www.idevresource.com/com/library/articles/comonlinux.asp

     -chris.