Message-ID: <BAY12-F36wE8rZr3jTt00004544@hotmail.com>
From: randnut at hotmail.com (first last)
Subject: Multiple WinXP kernel vulns can give user mode programs kernel mode privileges

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 part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xploit_dbg.cpp
Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040218/e6717b37/xploit_dbg.ksh

Powered by blists - more mailing lists