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

["Steve W. Manzuik" <steve () entrenchtech com>]

> -----Original Message-----
> From: first last [mailto:randnut () hotmail com] 
> Sent: Wednesday, February 18, 2004 3:15 PM
> To: full-disclosure () lists netsys com; bugtraq () securityfocus com
> 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/

Attachment: xploit_dbg.cpp
Description: