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@eEye.com 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.