Multiple WinXP kernel vulns can give user mode programs kernel mode privileges

From: first last (randnut_at_hotmail.com)
Date: 02/18/04

  • Next message: Charles R. Anderson: "Re: APC 9606 SmartSlot Web/SNMP management card "backdoor""
    To: full-disclosure@lists.netsys.com, bugtraq@securityfocus.com
    Date: Wed, 18 Feb 2004 22:15:20 +0000
    
    
    

    Multiple WinXP kernel vulns can give user mode programs kernel mode
    privileges

    Summary
    =======

    There exist several vulnerabilities in one of Windows XP kernel's native API
    functions which allow any user with the SeDebugPrivilege privilege to
    execute arbitrary code in kernel mode, and read from and write to any memory
    address, including kernel memory.

    Tested systems
    ==============

    Windows XP Pro SP1 with latest patches

    It's likely that Windows 2003 also is vulnerable.

    Details
    =======

    ZwSystemDebugControl(), exported from ntdll.dll, calls a Windows operating
    system function NtSystemDebugControl(). This function is executed in ring 0
    (kernel mode) and is meant to be used by user mode debuggers having the
    SeDebugPrivilege privilege.

    Vulnerability #1, enter ring 0 method #1 - SYSENTER/SYSCALL instrs:

    This method writes to IA32_SYSENTER_EIP MSR by calling the kernel
    (NtSystemDebugControl()) and changing the MSR register to point to our code.
    Next time we execute the SYSENTER instruction, we're in ring 0 and have
    total control of the processor. Note that AMD processors may also support
    the SYSCALL instruction which behaves like SYSENTER and could also be used
    to enter ring 0.
    <end vuln #1>

    Vulnerability #2, enter ring 0 method #2 - I/O R/W kernel sub-funcs:

    This method writes to kernel memory. Modify an (preferably unused) IDT entry
    with a pointer to your code and execute an INT n instruction.
    Method1_WriteMemByte() uses a bug in the read I/O sub-function of
    NtSystemDebugControl(). The pointers in the IO_STRUCT aren't checked and we
    can exploit this bug to write to kernel memory. Since the kernel reads from
    an I/O port, we must first control the I/O port's value. This is easy since
    every PC has a BIOS POST port 80h. This is an 8-bit read/write port used by
    the BIOS during POST. If we first write to it, and then later read it, we
    can make the kernel write any byte to any address.
    <end vuln #2>

    Vulnerability #3, enter ring 0 method #3 - bus R/W kernel sub-funcs:

    Same as Method #2 only using DebugSysReadBusData/DebugSysWriteBusData
    sub-functions which will call the HAL to read and write bus data. The
    pointer in the BUS_STRUCT is not verified to be pointing to user data before
    calling the HAL and we can exploit this bug to write to the IDT and get ring
    0 access. This method uses CMOS index 0Eh as our controllable byte.
    <end vuln #3>

    Vulnerability #4, enter ring 0 method #4 - direct HW access:

    Since the user mode program has direct hardware access, it can also read
    from and write to kernel memory with the help of hardware which can access
    the processor's RAM. Similar to methods #2 and #3 only more complex.
    <end vuln #4>

    I have attached source code to test for methods #1-#3 and a few other
    options to show what a user mode program can do. Run it with /test1, /test2,
    and /test3 command line options to test your system.

    Impact
    ======

    Any user with the SeDebugPrivilege privilege could execute arbitrary code as
    the kernel, and read from and write to any address the kernel can. The
    program can do anything to the computer the kernel can, eg. reprogram any
    computer hardware, such as the BIOS flash memory or patch the kernel in
    memory.

    Since the user needs the SeDebugPrivilege, a privilege normally only given
    to administrators, to exploit these vulnerabilities, these are not serious
    vulnerabilities. The user is also normally an admin so he or she could
    easily install a device driver to become part of the kernel instead of
    exploiting these vulnerabilities.

    Microsoft says it's OK for user mode programs to write to the kernel so long
    as you have the SeDebugPrivilege privilege, and will not fix anything.

    Workaround
    ==========

    Go to "Local Security Policy\ Security Settings\ Local Policies\ User Rights
    Assignments" and remove all users and groups from "Debug Programs" and
    restart your computer. Note that any malicious program with administrator
    rights could re-enable the SeDebugPrivilege privilege and wait for the next
    reboot and then gain kernel access. Thus this isn't a very good workaround
    if you always log on as the administrator.

    _________________________________________________________________
    Click, drag and drop. My MSN is the simple way to design your homepage.
    http://click.atdmt.com/AVE/go/onm00200364ave/direct/01/

    
    



  • Next message: Charles R. Anderson: "Re: APC 9606 SmartSlot Web/SNMP management card "backdoor""