OSEC

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

From: Steve W. Manzuik (steveentrenchtech.com)
Date: Wed Feb 18 2004 - 17:00:15 CST


 

> -----Original Message-----
> From: first last [mailto:randnuthotmail.com]
> Sent: Wednesday, February 18, 2004 3:15 PM
> To: full-disclosurelists.netsys.com; bugtraqsecurityfocus.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/
>