The passage of time has been good for computing…in most ways. But OS kernel development progresses through evolution, which means as new pieces of technology are attached, other pieces are discarded. And like evolution, at the core kernel level, some parts remain.

How does it occur?

So back in 1993, when Microsoft was still in the NT 3.1 environment, BIOS calls in the Virtual-8086 mode monitor code were introduced and have survived up to the time of Windows7. Microsoft, 17 years ago, detailed that there were vulnerabilities associated with this BIOS call.

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.  The flaw exists in the Virtual DOS Machine, which is a system that allows Windows NT to run DOS and 16bit applications on 386 (and up) machines.

Operating System Kernel

So what is the vulnerability?

Hackers can elevate an existing user account up to administrative privileges. Basically, what happens is that a 16 bit program can escalate its privileges and gain unrestricted access to the entire system.

What software is affected?

The Microsoft Security Advisory (979682) posting notes the following software that is vulnerable to this problem.

• Microsoft Windows 2000 Service Pack 4
• Windows XP Service Pack 2 and Windows XP Service Pack 3
• Windows Server 2003 Service Pack 2
• 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

Non-affected Software

• Windows XP Professional x64 Edition Service Pack 2
• Windows Server 2003 x64 Edition Service Pack 2
• Windows Server 2003 with SP2 for Itanium-based Systems
• Windows Vista x64 Edition, Windows Vista x64 Edition Service Pack 1, and Windows Vista x64 Edition Service Pack 2
• Windows Server 2008 for x64-based Systems and Windows Server 2008 for x64-based Systems Service Pack 2
• Windows Server 2008 for Itanium-based Systems and Windows Server 2008 for Itanium-based Systems Service Pack 2
• Windows 7 for x64-based Systems
• Windows Server 2008 R2 for x64-based Systems
• Windows Server 2008 R2 for Itanium-based Systems
• Solution and Workaround for 32 bit Windows7 editions.

What is the v8086 mode?

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.

The Workaround according to Microsoft

Click Start, click Run,
type gpedit.msc in the Open box, and then click OK.
This opens the Group Policy console.
1. Expand the Administrative Templates folder, and then click Windows Components.
2. Click the Application Compatibility folder.
3. In the details pane, double click the Prevent access to 16-bit applications policy setting. (By default, this is set to Not Configured.)
4. Change the policy setting to Enabled, and then click OK.

Other Workarounds:

The policy template “Windows ComponentsApplication CompatibilityPrevent  access to 16-bit applications” may be used within the group policy editor to prevent unprivileged users from executing 16-bit applications

1. Use the Group Policy Editor to enable the “Prevent access to 16-bit applications” in Computer ConfigurationAdministrative TemplatesWindows ComponentsApplication Compatibility. Or
2. Edit the registry directly by placing a key in HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsAppCompat with a D-Word value of VDMDissallowed = 1.

Results:

What is the result and impact of this workaround?  Quite simply users will not be able to run 16-bit applications.

How serious is this vulnerability – very or low?

Here are some elements of this vulnerability which make it a low risk option.

This vulnerability cannot be exploited remotely. Furthermore an attacker must already have access to a Windows computer containing a vulnerable version of the operating system. Moreover, the attacker would also need access to an account on that computer. Remote attacks are not possible, and the user must have an account or access to an account on the system in question.

Notes from Tavis Ormandy, a Google Engineer who first uncovered the bug. His remarks also appear here:

“Could Microsoft have avoided this issue? It’s difficult to imagine how, errors like this will generally elude fuzz testing (In order to observe any problem, a fuzzer would need to guess a 46-bit magic number, as well as setup an intricate process state, not to mention the VdmAllowed flag), and any static analysis would need an incredibly accurate model of the Intel architecture.”