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 alert@xxxxxxxx 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 info@xxxxxxxx
<<winmail.dat>>