EEYE: Windows Expand-Down Data Segment Local Privilege Escalation

From: Marc Maiffret (mmaiffret_at_EEYE.COM)
Date: 04/13/04

  • Next message: Marc Maiffret: "EEYE: Windows VDM TIB Local Privilege Escalation" 
    Date:         Tue, 13 Apr 2004 12:59:25 -0700
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

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

    Feedback
    Please send suggestions, updates, and comments to:

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

    -----
    NTBugtraq Editor's Note:

    Wondering how to unsubscribe from NTBugtraq? Just send a message to Listserv@listserv.ntbugtraq.com with unsubscribe ntbugtraq in the message body, you don't need a subject line. If it says you aren't subscribed, you've either subscribed with a different email address or your address has changed somehow. Just email Russ.Cooper@rc.on.ca and I'll remove you.
    -----

  • Next message: Marc Maiffret: "EEYE: Windows VDM TIB Local Privilege Escalation"

    Relevant Pages