US-CERT: Intel CPU Vulnerability

June 19, 2012

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.


Alan Turing Centenary, Part 1

June 19, 2012

I’ve written here a couple of time about the Alan Turing Centenary, marking the 100th anniversary of of the birth of the English mathematician, cryptanalyst, and pioneer computer scientist; and about some of the events planned for the occasion.  This coming Saturday, June 23, is Turing’s birthday, so there will undoubtedly be more events and tributes to follow.  In this, and subsequent posts, I’ll attempt to highlight some of the more interesting items that I come across.

Although it is not new, one item that deserves to be on the list is the wonderful biography of Turing by Andrew Hodges, Alan Turing: The Enigma.   Hodges also maintains The Alan Turing Home Page, a Web site dedicated to Turing.  It includes a short on-line biography, a scrapbook, and links to documents and publications.

Ars Technica has an article about Turing’s life and work, “The Highly Productive Habits of Alan Turing”, by Matthew Lasar, lecturer in history at the University of California, Santa Cruz.  It gives a good brief overview of Turing’s work, organized under seven “productive habits”:

  1. Try to see things as they are.
  2. Don’t get sidetracked by ideologies.
  3. Be practical.
  4. Break big problems down into smaller tasks.
  5. Just keep going.
  6. Be playful.
  7. Remember that it is people who matter.

If you aren’t familiar with Turing at all, this article is a good place to get the highlights quickly.

Wired has a couple of items on Turing.  The first is another brief biographical sketch, in the form of a time line of Turing’s life and work.  It mentions one occasion that I had forgotten: in the early 1950s, Turing wrote a program to play chess.  This was (pace Habit 3 above) not a very practical exercise, since at that time there was no computer powerful enough to run the program.  Turing tested the program by using an emulator — himself — executing the program with pencil and paper.

The second article at Wired is a more subjective look at some of Turing’s accomplishments.  It focuses mostly on his wartime work at the Government Code and Cypher School at Bletchley Park (also known as Station X), breaking the German’s Enigma encryption system, and on his work in computer science.  It also mentions Turing’s only paper on biology, “The Chemical Basis of Morphogenesis”, published in 1952.  Oddly, it doesn’t mention one of his best-known works, the essay Computing Machinery and Intelligence, published in October 1950 in the Oxford journal Mind, in which he proposes the “imitation game”, the Turing test of intelligence.

I’ll post additional items as I come across them.


%d bloggers like this: