Windows Expand-Down Data Segment Local Privilege Escalation Release Date: April 13, 2004 Date Reported: November 21, 2003 Severity: Medium (Local Privilege Escalation to Kernel) Vendor: Microsoft Systems Affected: Windows NT 4.0 Windows 2000 Description: eEye Digital Security has discovered a privilege escalation vulnerability in the Windows kernel that would allow any locally logged-in user to execute code with the highest possible privileges (kernel). A malicious user with legitimate but unprivileged access to a Windows system, or an attacker or worm payload able to acquire unprivileged access through an unrelated exploit, could take advantage of this vulnerability in order to completely compromise a Windows NT 4.0 or Windows 2000 machine. There are two separate but related flaws in the Windows kernel that cause the vulnerability described in this advisory to exist. The first problem is insufficient validation in the NtSetLdtEntries API function, which allows a security check to be bypassed and a potentially dangerous data segment to be created. The second issue is a lack of sanitization in certain portions of kernel code, leading to the modification of arbitrary memory locations if user code passes a reference to a malicious segment (created using NtSetLdtEntries) into the kernel. Technical Description: The NtSetLdtEntries API call allows a process to create a Local Descriptor Table (LDT) for itself, and to modify the descriptors contained therein. Although the function performs base and limit checking to ensure that a data segment encompassing kernel memory is not created, the function does not account for the effects of the Expand-Down flag (Type bit 2 for data segments), and as a result, we can create an expand-down data segment descriptor from which any part of memory is addressable. As long as the conditions "base < 7FFF0000h", "base <= base + limit" (to protect against integer overflows), and "base + limit < 7FFF0000h" are all satisfied, the descriptor will be successfully created. Although the details of expand-down data segments are beyond the scope of this advisory (but see References for a link to an excellent overview), it's sufficient to say that the limit on an expand-down segment indicates how much memory is excluded from, rather than included in the segment. On a normal segment, the memory from 'base' to 'base' + 'limit' is addressable from the segment; in the case of an expand-down data segment, addressable memory ranges from 'base' + 'limit' + 1 to 'base' - 1. With a limit of 0 and the Granularity bit set to 1, an expand-down segment encompasses all but 4KB of the 4GB virtual address space, but NtSetLdtEntries -- unaware of the effects of the expand-down flag on data segments -- interprets this as a segment that only covers 4KB of memory, and allows it to be created. This behavior is of course a flaw, but what makes it a vulnerability is that some kernel code uses the selectors it receives from user-mode code in the DS and ES registers, without any prior validation or sanitization. If NtSetLdtEntries performed proper input checking, then this would not be a problem either -- the idea is that, regardless of what hand-crafted segments they reference, DS and ES would only address user memory -- but because that protection mechanism can be bypassed, it is a problem. Most kernel code will throw an access violation if a pointer it receives references kernel memory (technically, if the address is 7FFF0000h or higher), but since the base of the effective segment is never taken into account, this check can be bypassed, and other fundamental assumptions about pointers being relative to virtual address 0 can be broken. For the sake of example, there is a REP MOVS instruction in the NTOSKRNL INT 2Eh interrupt handler that can be influenced to write to arbitrary locations in kernel memory. INT 2Eh is invoked by user code to call system routines in kernel code, and the MOVS instruction is performed to copy the function arguments supplied by the caller onto the kernel stack. Although most people know the operation of MOVS as copying data from ESI to EDI, meticulously technical readers and real-mode veterans will note that it actually copies from DS:ESI to ES:EDI. If ES references a non-zero-based data segment that addresses kernel memory, then the destination is "shifted" by the base of the segment. If the address of the kernel stack pointer can be determined (for instance, by causing this REP MOVS to first write detectable data into a large block of memory in user land, or by getting the kernel to "leak" the address), then the segment base can be configured such that the destination is any arbitrary address above the kernel stack pointer, such as the LDT. The epilog to this story is that, once arbitrary kernel memory can be modified to contain arbitrary values, a machine is wholly compromised. Protection: Retina Network Security Scanner has been updated to identify this vulnerability. Vendor Status: Microsoft has released a patch for this vulnerability. The patch is available at: http://www.microsoft.com/technet/security/bulletin/MS04-011.mspx. Credit: Derek Soeder Related Links: Retina Network Security Scanner - Free 15 Day Trial http://www.eeye.com/html/Products/Retina/download.html Greetings: Z0mbie, whose excellent "ldt2k" document was the impetus for this work. The fambly; everyone from AD2003!, plus friends, inmates, wardens... ;) and the one they call 0-Day (yes that's actually his name =] ). Copyright (c) 1998-2004 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@xxxxxxxx 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. Feedback Please send suggestions, updates, and comments to: eEye Digital Security http://www.eEye.com info@xxxxxxxx
<<winmail.dat>>