[NT] Microsoft DCOM RPC Race Condition (MS04-012)
From: SecuriTeam (support_at_securiteam.com)
To: firstname.lastname@example.org Date: 14 Apr 2004 08:53:28 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
- - - - - - - - -
Microsoft DCOM RPC Race Condition (MS04-012)
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.
* 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
The Activation class of functions within the RPCSS module is designed to
process incoming DCOM activation requests so that the instance can be
delivered to the requesting agent. Initiating two activation requests
simultaneously, and then quickly closing the connection can produce an
exploitable race condition. 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 might not be reliable across image versions due to the dramatic
changes in the address space.
Microsoft has released a patch for this vulnerability. The patch is
The information has been provided by <mailto:email@example.com> Marc
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: firstname.lastname@example.org
In order to subscribe to the mailing list, simply forward this email to: email@example.com
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.