OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Multiple WinXP kernel vulns can give user mode programs kernel mode privileges

From: first last (randnuthotmail.com)
Date: Wed Feb 18 2004 - 16:15:20 CST


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/