Microsoft Distributed Transaction Coordinator Memory Modification Vulnerability Release Date: October 11, 2005 Date Reported: July 8, 2005 Severity: High (Remote Code Execution) Vendor: Microsoft Systems Affected: Windows 2000 Server SP0 - SP4 - Vulnerable - Anonymous remotely exploitable by default Windows XP SP0 - SP1 - Not Vulnerable by default - Vulnerable if Service Started (Anonymously) Windows 2003 Server SP0 - Not Vulnerable by default - Vulnerable if anonymous Network DTC Access is enabled eEye ID#: EEYEB20050708 OSVDB #: 18828 CVE #: CAN-2005-2119 Overview: eEye Digital Security has discovered a critical vulnerability in the Microsoft Distributed Transaction Coordinator (MSDTC) service that would allow an anonymous attacker to take complete control over an affected system. MSDTC listens on TCP port 3372 and a dynamic high TCP port, and is enabled by default on all Windows 2000 systems. Technical Details: The Distributed Transaction Coordinator interface proxy (MSDTCPRX.DLL) functions as an RPC server that handles requests on the interface {906B0CE0-C70B-1067-B317-00DD010662DA} v1.0. Its MIDL_user_allocate function implementation features an unusual behavior in that will always allocate a single 4KB page of memory using VirtualAlloc, regardless of how much memory is requested. Therefore, allocation will always succeed and return a pointer to a 4KB block, entirely disregarding the allocation size -- which, in the case of the BuildContextW (opnum 7) RPC function, is specified by the caller. Because the memory is allocated using VirtualAlloc, it will not generally have any neighboring data that can be overwritten, but it turns out that the RPC run-time library itself has a behavior that can be exploited in conjunction with MSDTCPRX's unconventional allocation routine. As the following disassembly illustrates, RPCRT4.DLL's NdrAllocate function attempts to store certain management data after blocks it allocates: ; ESI = allocation size rounded up to 8-byte multiple ; EBX = total allocation size (alloc size + 0Ch) ; checked for integer overflow, so alloc size must be <= FFFFFFF0h 786F828D push ebx ; EBX = total alloc size 786F828E call dword ptr [edi+48h] ; MSDTCPRX.DLL!MIDL_user_allocate 786F8291 mov ebx, eax 786F8293 test ebx, ebx 786F8295 jz 78735490 786F829B lea eax, [esi+ebx] ; ESI = allocation size 786F829E lea ecx, [edi+0B0h] 786F82A4 mov dword ptr [eax], 4D454D4Ch ; +00h "LMEM" tag 786F82AA mov [eax+4], ebx ; +04h start of block 786F82AD mov edx, [ecx] 786F82AF mov [eax+8], edx ; +08h singly-linked list 786F82B2 mov [ecx], eax ; add this block to linked list Because the user-supplied allocation size is implicitly "validated" by the success of the allocation function, any size value FFFFFFF0h or less can be passed to NdrAllocate, and as a result, these 12 bytes of management data can be stored at an arbitrary address relative to the location of the VirtualAlloc'ed memory. The second of the three DWORD-size fields is a pointer to this memory, which facilitates exploitation even further. Protection: Retina, Network Security Scanner, has been updated to be able to identify this vulnerability. For more information on Retina visit: http://www.eEye.com/Retina Blink, Endpoint Vulnerability Prevention, already provides protection from attacks based on this vulnerability. For more information on Blink visit: http://www.eEye.com/Blink Vendor Status: Microsoft has released a patch for this vulnerability. The patch is available at: http://www.microsoft.com/technet/security/bulletin/MS05-051.mspx Credit: Fang Xing Greetings: Thanks Derek and eEye guys help me analyze and wrote the advisory, greetz xfocus and venus-tech lab's guys. Copyright (c) 1998-2005 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 (at) eEye (dot) com [email concealed] 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.