Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | [UNIX] Microsoft Distributed Transaction Coordinator Memory Modification (MS05-051) |
|---|---|
| Date: | 12 Oct 2005 09:29:26 +0200 |
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.
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [NT] Microsoft DirectShow Remote Code Vulnerability (MS05-050), SecuriTeam |
|---|---|
| Next by Date: | [NT] MDT2DD.DLL COM Object Uninitialized Heap Memory Vulnerability (MS05-052), SecuriTeam |
| Previous by Thread: | [NT] Microsoft DirectShow Remote Code Vulnerability (MS05-050), SecuriTeam |
| Next by Thread: | [NT] MDT2DD.DLL COM Object Uninitialized Heap Memory Vulnerability (MS05-052), SecuriTeam |
| Indexes: | [Date] [Thread] [Top] [All Lists] |