[UNIX] Microsoft Distributed Transaction Coordinator Memory Modification (MS05-051)

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.
http://www.securiteam.com/mailinglist.html

- - - - - - - - -

Microsoft Distributed Transaction Coordinator Memory Modification
(MS05-051)
------------------------------------------------------------------------

SUMMARY

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.

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.

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>
http://www.microsoft.com/technet/security/bulletin/MS05-051.mspx

CVE Information:
<http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2119>
CAN-2005-2119

ADDITIONAL INFORMATION

The information has been provided by <mailto:advisories@eeye.com> eEye.
The original article can be found at:
<http://www.eeye.com/html/research/advisories/AD20051011b.html>
http://www.eeye.com/html/research/advisories/AD20051011b.html

========================================

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: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
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.