Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   OS (Microsoft)  >   Windows Kernel Vendors:   Microsoft
Windows Kernel #GP Trap Handler Flaw Lets Local Users Gain Elevated Privileges
SecurityTracker Alert ID:  1023471
SecurityTracker URL:
CVE Reference:   CVE-2010-0232   (Links to External Site)
Updated:  Mar 3 2010
Original Entry Date:  Jan 19 2010
Impact:   Execution of arbitrary code via local system, Root access via local system
Fix Available:  Yes  Vendor Confirmed:  Yes  Exploit Included:  Yes  
Version(s): 2000 SP4, 2003 SP2, XP SP3, Vista SP2, 2008 SP2, 7; and prior service packs
Description:   A vulnerability was reported in Microsoft Windows. A local user can obtain elevated privileges on the target system.

A local user can exploit a flaw in the Virtual-8086 mode implementation to bypass security controls and execute arbitrary commands on the target system with elevated privileges.

The #GP trap handler (nt!KiTrap0D) allows a local user to switch the kernel stack to a user-controlled address.

Some demonstration exploit code is available at:

The vendor was notified on June 12, 2009.

x64-based systems are not affected.

Tavis Ormandy reported this vulnerability.

Impact:   A local user can obtain elevated privileges on the target system.
Solution:   The vendor has issued the following fixes:

Microsoft Windows 2000 Service Pack 4:

Windows XP Service Pack 2 and Windows XP Service Pack 3:

Windows Server 2003 Service Pack 2:

Windows Server 2003 with SP2 for Itanium-based Systems:

Windows Vista, Windows Vista Service Pack 1, and Windows Vista Service Pack 2:

Windows Server 2008 for 32-bit Systems and Windows Server 2008 for 32-bit Systems Service Pack 2:

Windows 7 for 32-bit Systems:

A restart is required.

On February 11 and 12, 2010, Microsoft reported that some customers are experiencing restart issues after applying this fix. Microsoft indicates that malware on the system can trigger the problem, but there may be other triggers. Microsoft has removed the MS10-015 fix from Windows Update while they investigate the problem, as described in these blog posts:

On February 18, 2010 (UTC), Microsoft reported that the reboot issue occurs on systems that are infected with the Alureon rootkit. Automatic updates have been re-enabled for 64-bit systems (which are not affected by Alureon). Updates for all systems are still available via Windows Update, WSUS, or SMS. More information is available at:

On March 3, 2010, Microsoft made MS10-015 available again via Automatic Updates. The patch is the same, but detection logic has been updated to check for conditions where MS10-015 may not properly install:

The Microsoft advisory is available at:

The original Microsoft advisory is available at:

Vendor URL: (Links to External Site)
Cause:   Access control error

Message History:   None.

 Source Message Contents

Subject:  [Full-disclosure] Microsoft Windows NT #GP Trap Handler Allows Users to Switch Kernel Stack

Microsoft Windows NT #GP Trap Handler Allows Users to Switch Kernel Stack


In order to support BIOS service routines in legacy 16bit applications, the
Windows NT Kernel supports the concept of BIOS calls in the Virtual-8086 mode
monitor code. These are implemented in two stages, the kernel transitions to
the second stage when the #GP trap handler (nt!KiTrap0D) detects that the
faulting cs:eip matches specific magic values.

Transitioning to the second stage involves restoring execution context and
call stack (which had been previously saved) from the faulting trap frame once
authenticity has been verified.

This verification relies on the following incorrect assumptions:

  - Setting up a VDM context requires SeTcbPrivilege.
  - ring3 code cannot install arbitrary code segment selectors.
  - ring3 code cannot forge a trap frame.

This is believed to affect every release of the Windows NT kernel, from
Windows NT 3.1 (1993) up to and including Windows 7 (2009).

Working out the details of the attack is left as an exercise for the reader.

Just kidding, that was an homage to Derek Soeder :-)

- Assumption 0: Setting up a VDM context requires SeTcbPrivilege.

Creating a VDM context requires EPROCESS->Flags.VdmAllowed to be set in order
to access the authenticated system service, NtVdmControl(). VdmAllowed can
only be set using NtSetInformationProcess(), which verifies the caller has
SeTcbPrivilege. If this is true, the caller is very privileged and can
certainly be trusted.

This restriction can be subverted by requesting the NTVDM subsystem, and then
using CreateRemoteThread() to execute in the context of the subsystem process,
which will already have this flag set.

- Assumption 1: ring3 code cannot install arbitrary code segment selectors.

Cpl is usually equal to the two least significant bits of cs and ss, and is
a simple way to calculate the privilege of a task. However, there is an
exception, Virtual-8086 mode.

Real mode uses a segmented addressing scheme in order to allow 16-bit
addresses to access the 20-bit address space. This is achieved by forming
physical addresses from a calculation like (cs << 4) + (eip & 0xffff). The
same calculation is used to map the segmented real address space onto the
protected linear address space in Virtual-8086 mode. Therefore, I must be
permitted to set cs to any value, and checks for disallowed or privileged
selectors can be bypassed (PsSetLdtEnties will reject any selector where any
of the three lower bits are unset, as is the case with the required cs pair).

- Assumption 2: ring3 code cannot forge a trap frame.

Returning to usermode with iret is a complicated operation, the pseudocode for
the iret instruction alone spans several pages of Intel's Software Developers
Manual. The operation occurs in two stages, a pre-commit stage and a
post-commit stage. Using the VdmContext installed using NtVdmControl(), an
invalid context can be created that causes iret to fail pre-commit, thus
forging a trap frame.

The final requirement involves predicting the address of the second-stage BIOS
call handler. The address is static in Windows 2003, XP and earlier operating
systems, however, Microsoft introduced kernel base randomisation in Windows
Vista. Unfortunately, this potentially useful exploit mitigation is trivial
to defeat locally as unprivileged users can simply query the loaded module list
via NtQuerySystemInformation().

Affected Software

All 32bit x86 versions of Windows NT released since 27-Jul-1993 are believed to
be affected, including but not limited to the following actively supported

    - Windows 2000
    - Windows XP
    - Windows Server 2003
    - Windows Vista
    - Windows Server 2008
    - Windows 7


Upon successful exploitation, the kernel stack is switched to an attacker
specified address.

An attacker would trigger the vulnerability by setting up a specially
formed VDM_TIB in their TEB, using a code sequence like this:

/* ... */
    // Magic CS required for exploitation
    Tib.VdmContext.SegCs = 0x0B;
    // Pointer to fake kernel stack
    Tib.VdmContext.Esi = &KernelStack;
    // Magic IP required for exploitation
    Tib.VdmContext.Eip = Ki386BiosCallReturnAddress;

    NtCurrentTeb()->Reserved4[0] = &Tib;
/* ... */

Followed by

/* ... */
    NtVdmControl(VdmStartExecution, NULL);
/* ... */

Which will reach the following code sequence via the #GP trap handler,
nt!KiTrap0D. Please note how the stack pointer is restored from the saved
(untrusted) trap frame at 43C3E6, undoubtedly resulting in the condition
described above.

/* ... */
.text:0043C3CE Ki386BiosCallReturnAddress proc near
.text:0043C3CE     mov     eax, large fs:KPCR.SelfPcr
.text:0043C3D4     mov     edi, [ebp+KTRAP_FRAME.Esi]
.text:0043C3D7     mov     edi, [edi]
.text:0043C3D9     mov     esi, [eax+KPCR.NtTib.StackBase]
.text:0043C3DC     mov     ecx, 84h
.text:0043C3E1     mov     [eax+KPCR.NtTib.StackBase], edi
.text:0043C3E4     rep movsd
.text:0043C3E6     mov     esp, [ebp+KTRAP_FRAME.Esi]
.text:0043C3E9     add     esp, 4
.text:0043C3EC     mov     ecx, [eax+KPCR.PrcbData.CurrentThread]
.text:0043C3F2     mov     [ecx+KTHREAD.InitialStack], edi
.text:0043C3F5     mov     eax, [eax+KPCR.TSS]
.text:0043C3F8     sub     edi, 220h
.text:0043C3FE     mov     [eax+KTSS.Esp0], edi
.text:0043C401     pop     edx
.text:0043C402     mov     [ecx+KTHREAD.Teb], edx
.text:0043C405     pop     edx
.text:0043C406     mov     large fs:KPCR.NtTib.Self, edx
.text:0043C40D     mov     ebx, large fs:KPCR.GDT
.text:0043C414     mov     [ebx+3Ah], dx
.text:0043C418     shr     edx, 10h
.text:0043C41B     mov     byte ptr [ebx+3Ch], dl
.text:0043C41E     mov     [ebx+3Fh], dh
.text:0043C421     sti
.text:0043C422     pop     edi
.text:0043C423     pop     esi
.text:0043C424     pop     ebx
.text:0043C425     pop     ebp
.text:0043C426     retn    4
/* ... */

Possibly naive example code for triggering this condition is availble from the
link below.

The code has been tested on Windows XP, Windows Server 2003/2008, Windows Vista
and Windows 7. Support for other affected operating systems is left as an
exercise for the interested reader.


If you believe you may be affected, you should consider applying the workaround
described below.

Temporarily disabling the MSDOS and WOWEXEC subsystems will prevent the attack
from functioning, as without a process with VdmAllowed, it is not possible to
access NtVdmControl() (without SeTcbPrivilege, of course).

The policy template "Windows Components\Application Compatibility\Prevent
access to 16-bit applications" may be used within the group policy editor to
prevent unprivileged users from executing 16-bit applications. I'm informed
this is an officially supported machine configuration.

Administrators unfamiliar with group policy may find the videos below
instructive. Further information is available from the Windows Server
Group Policy Home

To watch a demonstration of this policy being applied to a Windows Server 2003
domain controller, see the link below.

To watch a demonstration of this policy being applied to a Windows Server 2008
domain controller, see the link below.

To watch a demonstration of this policy being applied to a shared but
unjoined Windows XP Professional machine, see the link below.

On Windows NT4, the following knowledgebase article explains how to disable the
NTVDM and WOWEXEC subsystems.

Applying these configuration changes will temporarily prevent users from
accessing legacy 16-bit MS-DOS and Windows 3.1 applications, however, few users
require this functionality.

If you do not require this feature and depend on NT security, consider
permanently disabling it in order to reduce kernel attack surface.


Microsoft was informed about this vulnerability on 12-Jun-2009, and they
confirmed receipt of my report on 22-Jun-2009.

Regrettably, no official patch is currently available. As an effective and easy
to deploy workaround is available, I have concluded that it is in the best
interest of users to go ahead with the publication of this document without an
official patch. It should be noted that very few users rely on NT security, the
primary audience of this advisory is expected to be domain administrators and
security professionals.


This bug was discovered by Tavis Ormandy.


Greetz to Julien, Neel, Redpig, Lcamtuf, Spoonm, Skylined, asiraP, LiquidK,
ScaryBeasts, spender and all my other elite colleagues.

Check out some photography while at ring0 @


Derek Soeder has previously reported some legendary NT bugs, including multiple
vdm bugs that, while unrelated to this issue, make fascinating reading.

-, Windows VDM #UD LocalPrivilege Escalation
-, Windows VDM TIB Local Privilege Escalation
-, Zero Page Race Condition Privilege Escalation


SHA-1 checksum of follows.

Hash: SHA1


Version: GnuPG v1.4.5 (GNU/Linux)


------------------------------------- | finger me for my gpg key.

Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -

Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC