US-CERT: Intel CPU Vulnerability

The US Computer Emergency Readiness Team (US-CERT) has published a Vulnerability Note (VU#649219) about a newly discovered security vulnerability involving 64-bit operating systems or virtual machine hypervisors running on Intel x86-64 CPUs.   This does not affect Intel’s 64-bit Itanium processors. The vulnerability means that an attacker might be able to execute code at the same privilege level as the OS or hypervisor.

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.

The x86-64 architecture was originally developed by AMD, with the aim of producing a 64-bit CPU that was backward-compatible with the 32-bit IA32 architecture, as implemented in, for example, Intel’s Pentium processor.  The vulnerability exists because of a subtle difference between AMD’s implementation and Intel’s.  The good folks at the Xen open-source virtualization project have posted a detailed technical explanation of the problem on the Xen community blog; I will attempt a brief summary here.

Whether one is running a standard operating system, such as Linux or Windows, or a virtual machine hypervisor, such as Xen, a mechanism is needed to switch from an application, which runs with limited privileges, to the OS or hypervisor, which typically has no restrictions.  Of course, the mechanism must allow switching back, too.  The most commonly-used mechanism on the x86-64 platform uses a pair of instructions, SYSCALL and SYSRET.   The SYSCALL instruction does the following:

  • Copy the instruction pointer register (RIP) to the RCX register
  • Change the code segment selector to the OS or hypervisor value

A SYSRET instruction does the reverse; that is, it restores the execution context of the application.  (There is more saving and restoring to be done — of the stack pointer, for example — but that is the responsibility of the OS or hypervisor.)

The difficulty arises because the x86-64 architecture does not use 64-bit addresses; rather, it uses 48-bit addresses.  This gives  a 256 terabyte virtual address space, which is considerably more than is used today.   The processor has 64-bit registers, but a value to be used as an address must be in a canonical form (see the Xen blog post for details); attempting to use a value not in canonical form results in a general protection (#GP) fault.

The implementation of SYSRET in AMD processors effectively changes the privilege level back to the application level before it loads the application RIP.  Thus, if a #GP fault occurs because the restored RIP is not in canonical form, the CPU is in application state, so the OS or hypervisor can handle the fault in the normal way.  However, Intel’s implementation effectively restores the RIP first; if the value is not in canonical form, the #GP fault will occur while the CPU is still in the privileged state.  A clever attacker could use this to run code with the same privilege level as the OS.

According to the most recent version of the Vulnerability Note, the following systems are known to be affected by this vulnerability. when run on Intel CPUs: Citrix, Microsoft Windows 7 and Windows Server 2008R2, NetBSD, FreeBSD, Oracle, Xen, Red Hat Linux, SUSE Linux, and Joyent.   VMware and Apple systems are known not to be affected; and, of course, no system running on an AMD processor is affected.  Check the links in the Vulnerability Note for more information.

Intel says that this is not a flaw in their CPU, since it works according to their written spec.  However, since the whole point of their implementation was to be compatible with the architecture as defined originally by AMD, this seems a bit disingenuous.

The immediate risk of successful exploits “in the wild” is probably not that high.  However, hardware flaws don’t get fixed overnight, so I hope the OS vendors can implement a software work-around (as Xen has already done) without too much delay.

Comments are closed.

%d bloggers like this: