Message-ID: <7BE3FADD73E3734AA95BCA7AE4802F30573D4F@hermes.eCompany.gov>
Date: Tue, 13 Apr 2004 12:59:17 -0700
From: "Marc Maiffret" <mmaiffret@...e.com>
To: <BUGTRAQ@...URITYFOCUS.COM>
Subject: EEYE: Windows Expand-Down Data Segment Local Privilege Escalation


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@...e.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.

Feedback
Please send suggestions, updates, and comments to:

eEye Digital Security
http://www.eEye.com
info@...e.com

Powered by blists - more mailing lists