There is a new security warning from US CERT (Computer Emergency Readiness Team) for some virtualized systems running on Intel CPUs. According to researchers, some 64-bit operating systems and virtualization software running on
Intel CPU hardware are vulnerable to a local privilege escalation
attack. The vulnerability may be exploited for local privilege
escalation or a guest-to-host virtual machine escape.
According to US CERT KB VU#649219 - A ring3 attacker may be able to specifically craft a stack frame to be executed by ring0 (kernel) after a general protection exception (#GP). The fault will be handled before the stack switch, which means the exception handler will be run at ring0 with an attacker's chosen RSP causing a privilege escalation.
What this means is that someone may be able to cause a system exception in virtualized code and escape from the guest OS into the host environment with elevated privileges. Intel and AMD package security features that are supposed to isolate the guest operating systems from each other from the host to prevent this type of attack. Unfortunately, it looks as though there may be a flaw in Intel’s implementation of this protection schema that allows an attacker to break free and jump into the protected host OS.
However, not all virtualization platforms are affected. But the list does include quite a few vendors, so make sure your platform isn't on the list. If it is, be sure to review the Vendor information for specific patch and workaround details.
Those that are listed as being affected include: Citrix, FreeBSD Project, Intel Corporation, Joyent, Microsoft, NetBSD, Oracle, Red Hat, SUSE Linux and Xen. VMware, Apple and AMD appear to be unaffected.
Details from Xen
CVE-2012-0217 / XSA-7 - 64-bit PV guest privilege escalation vulnerability
A vulnerability which can allow a 64-bit PV guest kernel running on a 64-bit hypervisor to escalate privileges to that of the host by arranging for a system call to return via sysret to a non-canonical RIP. Intel CPUs deliver the resulting exception in an undesirable processor state.
Details from FreeBSD
FreeBSD-SA-12:04.sysret: Privilege escalation when returning from kernel
FreeBSD/amd64 runs on CPUs from different vendors. Due to varying behaviour of CPUs in 64 bit mode a sanity check of the kernel may be insufficient when returning from a system call. Successful exploitation of the problem can lead to local kernel privilege escalation, kernel data corruption and/or crash.
Details from Microsoft
User Mode Scheduler Memory Corruption Vulnerability - MS12-042 - Important
An elevation of privilege vulnerability exists in the way that the Windows User Mode Scheduler handles system requests. An attacker who successfully exploited this vulnerability could run arbitrary code in kernel mode. An attacker could then install programs; view, change, or delete data; or create new accounts with full administrative rights.
Mitigating Factors for User Mode Scheduler Memory Corruption Vulnerability
Mitigation refers to a setting, common configuration, or general best-practice, existing in a default state, that could reduce the severity of exploitation of a vulnerability. The following mitigating factors may be helpful in your situation:
Details from Red HatRHSA-2012:0720-1 & RHSA-2012:0721-1: It was found that the Xen hypervisor implementation as shipped with Red Hat Enterprise Linux 5 did not properly restrict the syscall return addresses in the sysret return path to canonical addresses. An unprivileged user in a 64-bit para-virtualized guest, that is running on a 64-bit host that has an Intel CPU, could use this flaw to crash the host or, potentially, escalate their privileges, allowing them to execute arbitrary code at the hypervisor level. (CVE-2012-0217, Important)
- An attacker must have valid logon credentials and be able to log on locally to exploit this vulnerability. The vulnerability could not be exploited remotely or by anonymous users.
- This vulnerability only affects Intel x64-based versions of Windows 7 and Windows Server 2008 R2.
- Systems with AMD or ARM-based CPUs are not affected by this vulnerability.
Details from some affected vendors were not available at the time of publication.