11/10/05, 23:15
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 =3D allocation size rounded up to 8-byte multiple
; EBX =3D total allocation size (alloc size + 0Ch)
; checked for integer overflow, so alloc size must be <=3D FFFFFFF0h
786F828D push ebx ; EBX =3D 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 =3D 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=20
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.
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 =3D allocation size rounded up to 8-byte multiple
; EBX =3D total allocation size (alloc size + 0Ch)
; checked for integer overflow, so alloc size must be <=3D FFFFFFF0h
786F828D push ebx ; EBX =3D 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 =3D 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=20
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.