[Full-Disclosure] EEYE: Microsoft DCOM RPC Race Condition

Microsoft DCOM RPC Race Condition

Release Date:
April 13, 2004

Date Reported:
September 10, 2003

Severity:
High (Remote Code Execution)

Vendor:
Microsoft

Systems Affected:
Microsoft Windows NT Workstation 4.0
Microsoft Windows NT Server 4.0
Microsoft Windows NT Server 4.0, Terminal Server Edition
Microsoft Windows 2000
Microsoft Windows XP
Microsoft Windows Server 2003

Description:
eEye Digital Security has discovered a critical remote vulnerability in
the way Microsoft Windows handles DCOM RPC requests. This vulnerability
is a separate issue from vulnerabilities described in Microsoft Security
Bulletins MS03-026 and MS03-039.

The RPC (Remote Procedure Call) protocol provides an inter-process
communication mechanism allowing a program running on one computer to
execute code on a remote system. Distributed COM (DCOM) extends the
usability of COM to support COM communication across a network with
other computers. The DCOM RPC interface in charge of processing incoming
RPC based DCOM activation requests has been prone to failure in the
past. An issue in the DCOM interface dealing with the processing of
incoming activation requests can be exploited remotely to overwrite heap
memory and gain control of the vulnerable RPC server with SYSTEM level
privileges.

Technical Description:
The Activation class of functions within the RPCSS module are designed
to process incoming DCOM activation requests so that the instance can be
delivered to the requesting agent. An exploitable race condition can be
produced by initiating two activation requests simultaneously, and then
quickly closing the connection. The window of opportunity to produce
this condition is very slim so multiple parallel requests will usually
be required to produce this condition. Producing this condition will
cause a small amount of corruption within the svchost rpc service
process heap.

Due to the volatile nature of this vulnerability several different
objects may be overwritten depending on the block the memory management
supplies us. We can increase the rate of success by altering the size of
our request so that a less populated block pool is chosen.

Navigating to a desired payload proved difficult because of the fact
that several different objects could be overwritten depending on what
block we overwrite. Given we couldn't supply a general purpose return
address that met each of conditions we observed, we combined this issue
with the memory leak released in unison with this advisory. Using the
memory leak we can inject a payload into the process heap and it will
reside there inevitably. Unfortunately due to the nature of the Windows
heap an address cannot easily be predicted without access to the private
heap environment.

When a request is made to the memory management for a block 30000 bytes
in size, the memory management system will page in virtual memory,
skipping the private heap and its blocks. The memory management system
will locate an unused area of the process address space with enough
space for our requested memory. By supplying an irregularly large size
with our allocation we can force the memory management system to supply
us with memory at an address that is predictable. It should be noted
that this technique may not be reliable across image versions due to the
dramatic changes in the address space.

Protection:
Retina Network Security Scanner has been updated to identify this
vulnerability.

Vendor Status:
Microsoft has released a patch for this vulnerability. The patch is
available at:
http://www.microsoft.com/technet/security/bulletin/MS04-012.mspx.

Credit:
Discovery: Riley Hassell
Additional Research: Derek Soeder and Barnaby Jack

Related Links:
Retina Network Security Scanner - Free 15 Day Trial
http://www.eeye.com/html/Products/Retina/download.html

Greetings:
Celeste, Eliza, K2, Nishad, FX, Halvar Flake, Solar Designer, and to the
pioneers of fault injection and fuzz testing: Henrique Madeira, M.rio
Rela, Francisco Moreira, and Jo.o Gabriel Silva, G.A. Kanawati, N.A.
Kanawati, J.A. Abraham, Justin E. Forrester, Barton P. Miller, Anup K.
Ghosh, Tom O'Connor, and Gary McGraw.

Copyright (c) 1998-2004 eEye Digital Security
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express
consent of eEye. If you wish to reprint the whole or any part of this
alert in any other medium excluding electronic medium, please email
[email protected] for permission.

Disclaimer
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There
are no warranties, implied or express, with regard to this information.
In no event shall the author be liable for any direct or indirect
damages whatsoever arising out of or in connection with the use or
spread of this information. Any use of this information is at the user's
own risk.

Feedback
Please send suggestions, updates, and comments to:

eEye Digital Security
http://www.eEye.com
[email protected]