The problem has been discovered in the Virtual DOS Machine (VDM) introduced in 1993 to support 16-bit applications (real mode applications for 8086). VDM is based on the Virtual 8086 Mode (VM86) in 80386 processors and, among other things, intercepts hardware routines such as BIOS calls. Google security team member Tavis Ormandy has found several vulnerabilities in this implementation that allow an unprivileged 16-bit program to manipulate the kernel stack of each process via a number of tricks. This potentially enables attackers to execute code at system privilege level.
In addition to the unpatched hole in Internet Explorer, a now published hole in Windows allows users with restricted access to escalate their privileges to system level – and this is believed to be possible on all 32-bit versions of Windows from Windows NT 3.1 up to, and including Windows 7. While the vulnerability is likely to affect home users in only a minor way, the administrators of corporate networks will probably have their hands full this week.
The problem is caused by flaws in the Virtual DOS Machine (VDM) introduced in 1993 to support 16-bit applications (real mode applications for 8086). VDM is based on the Virtual 8086 Mode (VM86) in 80386 processors and, among other things, intercepts hardware routines such as BIOS calls. Google security team member Tavis Ormandy has found several vulnerabilities in this implementation that allow an unprivileged 16-bit program to manipulate the kernel stack of each process via a number of tricks. This potentially enables attackers to execute code at system privilege level.
Ormandy has also published a suitable exploit which functions under Windows XP, Windows Server 2003 and 2008, Windows Vista and Windows 7. When tested by the The H’s associates at heise Security, the exploit opened a command prompt in the system context, which has the highest privilege level, under Windows XP and Windows 7. No patch has become available, although Ormandy reports that Microsoft was already informed of the hole in mid 2009. The developer decided to publish the information regardless because, in his opinion, there is a simple workaround: to disable the MS-DOS subsystem.
The workaround requires users to start the group policy editor and enable the “Prevent access to 16-bit applications” option in the Computer ConfigurationAdministrative TemplatesWindows ComponentsApplication Compatibility section. When tested with these settings by the heise Security team, the exploit no longer functioned. The settings reportedly don’t cause any major compatibility problems for most users while no 16-bit applications are being used.
Update – The above option is only available through the group policy editor on Windows 2003 systems. Some versions of Windows do not include a group policy editor. As an alternative, users can also create a registry key under HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsAppCompat with a D-Word value of VDMDissallowed = 1. Under Windows XP, to prevent the system from being vulnerable to the exploit, users can place the following text:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsAppCompat]
“VDMDisallowed”=dword:00000001
into a file called vdmdisallow.reg and double click the file. Windows will then automatically import the key (admin rights are required to perform this action).
Update 2 -Â Microsoft has now confirmed the privilege escalation hole in Windows. The company says that it wants to complete its investigation of the vulnerability and will then decide whether, how and when to close it.
See Also:
- Microsoft Windows NT #GP Trap Handler Allows Users to Switch Kernel Stack, security advisory from Travis Ormandy.
REDMOND — When it rains, it pours. Especially in the Seattle area. Tavis Ormandy has published full details on a privilege escalation hack of all versions of Windows including Windows 7.
The exploit takes advantage of a bug in the Windows implementation of the ‘virtual DOS machine’ used to run legacy 16-bit programs. The exploit can be avoided by turning the VDM ‘feature’ off but the danger of course is that enough Windows lusers won’t know about the bug and/or bother turning the ‘feature’ off.
16-bit applications need BIOS support; the Windows kernel supports virtual BIOS interrupts in its ‘Virtual-8086’ mode monitor code. The code is implemented in two stages. The #GP trap handler transitions to the second stage when CS:EIP faults with specific ‘magic’ values.
The transition requires (subsequent to authentication) restoring the context and the call stack from the faulting trap frame. But the authentication process is flawed, relying as it does on three incorrect assumptions.
- Setting up a VDM context requires SeTcbPrivilege.The barrier to getting a VDM context can be subverted by requesting the NT VDM subsystem and then using CreateRemoteThread() to run code in the context of the VDM subsystem. The VDM subsystem already has the necessary flag set.
- Ring 3 (unprivileged) code cannot install arbitrary code segment selectors.Using the two least significant bits of CS/SS to calculate the privilege of a task doesn’t work when it comes to Virtual-8086 mode. The 20-bit addressing (by adding CS << 4 to the 16-bit IP) is also used to map onto the protected linear Virtual-8086 address space. If CS can be set to an arbitrary value, then the privilege calculation can be circumvented.
- Ring 3 (unprivileged) code cannot forge a trap frame.Returns to user mode are through IRET. An invalid context can cause IRET to fail pre-commit, which in turn forges a trap frame. And even with address randomisation it’s trivial to use NtQuerySystemInformation() to obtain the address of the second stage BIOS handler.
Affected Systems
This bug dates back 17 years and affects all systems released since 27 July 1993 – Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, and Windows 7. See the links below for further details.
See Also
MITRE: CVE-2010-0232
Windows plagued by 17-year-old privilege escalation bug
NEOPHASIS: Trap Handler Allows Users to Switch Kernel Stack