The vulnerability, which is unpatched, essentially allows an attacker to bypass several major security mitigations — Data Execution Prevention (DEP), Safe Exception Handlers (SafeSEH) and Address Space Layout Randomization (ASLR) — to exploit the Windows operating system.
As a result, some applications with bugs that are not exploitable when running in a not-virtualized operating system are rendered exploitable if running within a guest OS in Virtual PC, according to Ivan Arce, chief technology officer at Core.
The flaw, discovered by Core exploit writer Nicolas Economou, exists in the memory management of the Virtual Machine Monitor. It causes memory pages mapped above the 2GB level to be accessed with read or read/write privileges by user-space programs running in a Guest operating system.
Affected software includes Microsoft Virtual PC 2007, Virtual PC 2007 SP1, Windows Virtual PC and Microsoft Virtual Server 2005. On Windows 7 the XP Mode feature is also affected by the vulnerability.
In particular, a vulnerable application running in Windows XP Mode on Windows 7 may be exploitable in a virtual environment, while the same application running directly on a Windows XP SP3 operating system is not.
Microsoft Hyper-V technology is not affected by this problem.
Arce said Core reported the flaw to Microsoft last August — more than seven months ago — but after back-and-forth discussions, the company decided it would not issue a security bulletin to provide patches.
“They [Microsoft] said that they agreed with our assessment of the problem, that it makes DEP/SafeSEH and ASLR bypassable. However, they say it doesn’t meet their criteria for a security bulletin and that they’ll fix in a service pack or a future product update,” Arce explained in a telephone interview from his office in Buenos Aires, Argentina.
“Given that that’s their decision, we feel we have to inform people of the risk so they can make informed decisions,” he added. “We consider this a vulnerability that needs to be fixed.”
Microsoft officials declined to comment until they had a chance to review Core’s advisory on the issue. (See update below)
Microsoft’s Virtual PC hypervisor is an element of the company’s Windows Virtual PC package, which allows users to run multiple Windows environments on a single computer. The hypervisor is a key component of Windows 7 XP Mode, a feature in Microsoft’s latest desktop operating system aimed at easing the migration path into the new OS for users and enterprises that need to run legacy Windows XP applications on its native OS.
With this discovery, Arce said it may transform a certain type of common software bug into exploitable vulnerabilities. “Certain vulnerabilities that have been dismissed as non-exploitable may now be exploitable on virtualized environments,” he said. “Let’s say someone found a vulnerability 2-3 years ago in a virtual application. They did the analysis and determined it was not exploitable because it only caused a crash in the client app. Now, you can bypass DEP and SafeSEH and that same vulnerability or a large list of vulnerabilities may be exploitable on on virtualized systems.”
Core recommends that affected users run all mission critical Windows applications on native iron or use virtualization technologies that aren’t affected by this vulnerability.
Windows operating systems and applications that must run virtualized using Virtual PC technologies should be kept at the highest patch level possible and monitored to detect exploitation attempts.
“This particular case provides a good example of how mechanisms designed to improve an operating system’s security over many years can eventually become ineffective when some of the basic underlying aspects of their operation are changed by virtualization technology,” Arce said.
UPDATE #1: Here is a link to Core’s advisory, which includes a technical description of the issue and proof-of-concept code.
UPDATE #2: Here is Microsoft’s official response:
Core Security Technologies is describing a way for an attacker to more easily exploit security vulnerabilities already present on the system, rather than an actual vulnerability. It does this by rendering a number of protection mechanisms that are present in the Windows kernel less effective inside a virtual machine as opposed to a physical Windows machine. An attacker would need to abuse an already present vulnerability in order to leverage this technique.
In the scenario Core describes, the functionality is limited to within the virtualized environment– in other words, an attacker could only exploit a vulnerability in an application running “inside” the guest virtual machine on Windows XP rather than Windows 7 in the case of Windows XP Mode. Specially an attacker could not take over a whole host machine running multiple virtual machines. The safeguards within Windows 7 on the desktop OS (DEP, ASLR, and SafeSEH etc.) remain in place.
In addition, an actual vulnerability must already be present in an application running in the guest machine in order for an attacker to take advantage of this. The difference is that on a regular Windows system, that bug may not be exploitable, whereas in the Virtual PC guest machine, it potentially could be.
Microsoft continues to recommend using Windows XP Mode and Windows Virtual PC as a bridging strategy to Windows 7 if they are concerned about compatibility for some of their legacy applications, so that customers can realize the full security benefits Windows 7 offers.
This Windows security blog post from Microsoft adds some additional commentary.