Skip to content


The Intel SYSRET privilege escalation

The Xen Security team recently disclosed a vulnerability, Xen Security Advisory 7 (CVE-2012-0217), which would allow guest administrators to escalate to hypervisor-level privileges. The impact is much wider than Xen; many other operating systems seem to have the same vulnerability, including NetBSD, FreeBSD, some versions of Microsoft Windows (including Windows 7).

So what was the vulnerability? It has to do with a subtle difference in the way in which Intel processors implement error handling in their version of AMD’s SYSRET instruction. The SYSRET instruction is part of the x86-64 standard defined by AMD. If an operating system is written according to AMD’s spec, but run on Intel hardware, the difference in implementation can be exploited by an attacker to write to arbitrary addresses in the operating system’s memory. This blog will explore the technical details of the vulnerability.

It should be noted that there are some questions about the way in which the disclosure process for this vulnerability was handled. In order to make sure that everyone can fully participate in the discussion, including system administrators who may at this moment be patching their systems, there has been a conscious decision to postpone any discussion about the disclosure process for one week, until the 19th of June.

Introduction: Canonical addresses, Context switch, and SYSRET

The first concept to understand is that of canonical addresses. When designing the 64-bit extensions to x86, AMD didn’t extend the actual virtual address space to a full 64 bits, but only to 48 bits. (This was mainly done to balance the benefits of extended address spaces with the cost of extra levels of the page table: 64 bits of virtual address space would have required a 6-level pagetable; 48 bits gives you 256 terabytes of virtual address space, far more than the largest machines will have for many years to come, and only requires 4 levels of pagetable.)

They could have made the processor just ignore the extra 16 bits of address space, but clever programmers have a tendency to take advantage of these kinds of quirks to do things like storing extra information in the “unused” portions of virtual addresses. These clever tricks would break, however, if the processors ever decided to extend the address space into more bits. In order to prevent this, they put in restrictions to the microprocessor: Any 64-bit value that is used as a virtual address (for instance, written into the instruction pointer register, RIP) must be in canonical form: That is, bits 48-63 must be the same as bit 47. Valid (or “canonical”) addresses space thus exists in two non-contiguous 128-terabyte chunks: from 0x0000000000000000-0x00007fffffffffff, and then from 0xffff800000000000-0xffffffffffffffff. Any time a 64-bit value is used as a virtual address that does not fit in one of these two ranges, the processor will throw a general protection fault (#GP).

The next thing to understand is the process of context switching between the guest and the hypervisor. Whenever switching from a lower privilege to a higher privelege (either a kernel or a hypervisor), the registers of the lower-level privilege must be saved and replaced with those of the higher privilege. When an interrupt or exception is delivered while in guest mode, the RIP, stack pointer, and code segment (which encodes the privilege level) are changed by the hardware; the hypervisor then stores the rest of the guest state on its stack, and handles the interrupt.

In the early days of x86, a system call was treated as a special-case of an interrupt or exception: typically the guest would execute INT instruction to enter the hypervisor or operating system, and the hypervisor would execute IRET to return to the guest. But both AMD and Intel’s performance analysis teams determined that for processes which made a significant number of system calls, going through the normal exception path in the processor was significantly slower. So they independently came up with special instructions for voluntarily escalating privilege: AMD came up with SYSCALL/SYSRET, and Intel came up with SYSENTER/SYSEXIT. They have slightly different semantics, and they’re not available in all modes on both processors. Since SYSRET is part of the x86-64 standard, and available on all processors in 64-bit mode, it’s common for 64-bit operating systems and hypervisors to use it exclusively.

Intel’s version of SYSRET, however, has a very subtle difference in behavior than AMD’s version. It is this difference that is the source of the problem.

SYSRET on Intel and AMD

The key difference between SYSCALL/SYSRET and INT / IRET is how much information is stored and where. SYSCALL/SYSRET instructions only save and restore the RIP of the guest, as well as changing the code segment selector (which effectively changes the privilege level). Furthermore, rather than reading IDTs and writing to stack frames, the instructions copy the guest RIP to and from the RCX register, and the segment selectors and hypervisor RIP to and from various other processor registers. The hypervisor is responsible for saving and restoring all of the other registers, including the stack pointer (RSP).

So the end-to-end effect of the SYSRET instruction, on both Intel and AMD, is as follows:

  • Load RIP from RCX
  • Change code segment selector to guest mode

Now, as we said before, RIP is used as a virtual address, so it must be canonical. RCX, however, is a general purpose register, and may contain any 64-bit number. So if for some reason there is a non-canonical address in RCX, upon executing the SYSRET instruction, the processor will throw a general protection fault (#GP).

Now here comes the subtle difference. The AMD and Intel architecture specifications include pseudocode that is meant to be a precise description of what the instruction does. In the AMD pseudocode, there is no explicit mention of the check for a canonical address; however, the actual RIP is not assigned until after the privilege level has been changed back to guest mode; and experimentation has confirmed that a SYSRET executed on AMD with a non-canonical address in RCX will throw the #GP in guest mode. However, in the Intel pseudocode, the check for a guest canonical address is explicit, and happens before the privilege level is changed. This means that if a SYSRET is executed on an Intel processor with a non-canonical address in RCX, the processor will throw a #GP in priveleged mode.

It’s a subtle difference, but it’s important, because the value of the stack pointer used when the processor delivers a #GP will change depending on the privilege level. If a #GP is delivered in guest mode, the processor will load the hypervisor’s RSP from a special hypervisor-designated entry point. But if the #GP is delivered while in hypervisor mode, the processor will use the current RSP, so that it can effectively “nest” the exception.

But recall that the SYSRET instruction doesn’t restore the RSP; the hypervisor has to do that. So by the time the #GP happens, the hypervisor has already restored the RSP to what was in the guest’s RSP when it did the SYSCALL, along with all of the other general-purpose registers.

So if the guest can induce the hypervisor to have a non-canonical RIP to return to, it can set the RSP to any value it wants to in hypervisor memory, and get the hardware (in delivering a #GP) to overwrite it. This can in turn be leveraged into a full exploit (the details of which are left as an exercise to the reader).

The fix in Xen’s case is, on the SYSRET return path, to check to make sure that RCX is canonical. If it is not, Xen will fall back to the slower IRET path, which will behave as expected.

The fall-out

I’ve used “hypervisor” and “guest” because that’s how it affects Xen; but it should be clear that the same exact attack might work against operating systems as well. And it turns out that it does. It seems that 64-bit versions of NetBSD, FreeBSD, and Microsoft Windows 7 were all vulnerable.

OpenBSD and Linux were not vulnerable. Linux actually fixed the bug in 2006, with CVE-2006-0744. But the description says “Linux kernel before 2.6.16.5 does not properly handle uncanonical return addresses on Intel EM64T CPUs…”, which makes it sound like something Linux-specific. It’s therefore not surprising that it attracted little notice from other operating systems.

Because Intel’s implementation of SYSRET matches their published spec, they consider their processors to be behaving correctly. However, the SYSRET instruction was defined by AMD as part of the x86-64 architecture, and Intel’s version is obviously intended to be compatible with AMD’s version. If the majority of operating systems (acting independently) managed to “not properly handle uncanonical return addresses on Intel EM64T CPUs”, it’s hard not to conclude that Intel made a mistake when designing their specification.


Be Sociable and Share!

Posted in Xen Development, Xen Security.

Tagged with , , .


27 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

Continuing the Discussion

  1. The Intel SYSRET privilege escalation – blog.xen.org « IT Corner linked to this post on June 13, 2012

    [...] more here:  The Intel SYSRET privilege escalation – blog.xen.org Tagged as: 2-6-16-5-does, description, have-the, have-the-same, intel, linux, microsoft, [...]

  2. Linode Blog » Xen Security Advisories and How We Handled Them linked to this post on June 13, 2012

    [...] Xen blog has a really nice writeup on the [...]

  3. Xen exploit! Juni 2012 linked to this post on June 14, 2012

    [...] di kernel intel (sama amd juga?) dan cuma Xen yg sampai detik ini nemuin/release bug fixnya. The Intel SYSRET privilege escalation – blog.xen.org jadi buat yang punya virtualisasi lain (hypervisor) silahkan di cek juga. Reply [...]

  4. Повышение привилегий в Intel SYSRET | PlainText linked to this post on June 15, 2012

    [...] По материалам блога разработчиков Xen Теги: virtualization, vulnerability [...]

  5. US-CERT discloses security flaw in Intel chips « I Web Guy Blog linked to this post on June 16, 2012

    [...] of the SYSRET instruction, which is part of the x86-64 standard defined by Advanced Micro Devices, according to the Xen community blog. “If an operating system is written according to AMD’s spec, but run on Intel hardware, [...]

  6. Security Researchers Find Hardware-Level Security Flaw in Intel Processors | WebTool Plugin For WordPress linked to this post on June 17, 2012

    [...] Given that AMD chips aren’t affected and AMD wrote the x86-64 standard that Intel later copied, we’re a bit dubious of the company’s attempt to push this off as a software problem. The subtle difference alluded to above is precisely that certain hardware functions are performed differently on Intel CPUs than on AMD chips. As the Xen.org blog states: [...]

  7. BlackThorne.DK » Mikrokode opdatering fra Intel linked to this post on June 17, 2012

    [...] bits instruktionssæt en smule anderledes end AMD selv. Selve problemet er forklaret ret godt på Xen’s blogside om [...]

  8. US-CERT Reveals Security Defect In Intel 64-bit Chips | TheTechJournal linked to this post on June 17, 2012

    [...] to the Xen community blog “If an operating system is written according to AMD’s spec, but run on Intel hardware, [...]

  9. US-CERT Reveals Security Defect In Intel Chips « GuruSpot: Gadget linked to this post on June 18, 2012

    [...] to a Xen village blog “If an handling complement is created according to AMD’s spec, though run on Intel hardware, a [...]

  10. US-CERT: lỗi nguy hiểm trong chip xử lý Intel – Tuổi Trẻ | Danh bạ Xóm tôi linked to this post on June 18, 2012

    [...] Lỗ hổng bảo mật này xuất phát từ cách mà các CPU thực hiện xử lý lỗi trong phiên bản của các hướng dẫn SYSRET, vốn là một phần của tiêu chuẩn x84-64 được định nghĩa bởi AMD (Advanced Micro Devices). Hiểu đơn giản, nếu một hệ điều hành được xây dựng dựa theo các tiêu chuẩn của AMD nhưng lại chạy trên phần cứng của Intel, sự khác biệt trong quá trình triển khai hệ thống có thể bị khai thác. Chi tiết về lỗi có thể tham khảo từ website của Xen. [...]

  11. US-CERT warns of Intel chip security flaw | CISSP 2 CISSP linked to this post on June 18, 2012

    [...] of the SYSRET instruction, which is part of the x86-64 standard defined by Advanced Micro Devices, according to the Xen community blog. “If an operating system is written according to AMD’s spec, but run on Intel hardware, [...]

  12. FDS-Team » Sicherheitslücke bei 64 Bit Intel Prozessoren linked to this post on June 18, 2012

    [...] sich für den technischen Hintergrund interessiert, findet unter http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-privilege-escalation/ eine Beschreibung zu den Auswirkungen des CPU Bugs auf den XEN Hypervisor. Durch die Bekanntheit [...]

  13. US-CERT discloses security flaw in Intel chips | CSO Security and Risk | ThreatCase linked to this post on June 18, 2012

    [...] of the SYSRET instruction, which is part of the x86-64 standard defined by Advanced Micro Devices, according to the Xen community blog. “If an operating system is written according to AMD’s spec, but run on Intel hardware, [...]

  14. Security Flaw in Intel 64-bit Chips | Anton Schieffer linked to this post on June 18, 2012

    [...] you want a slightly more technical explanation of how this bug works, check out Xen’s blog – Xen is an open-source virtualization company whose products were affected (and have since [...]

  15. El bug “Intel SYSRET fault” y la importancia de las comunidades | Phenobarbital con Soda! linked to this post on June 19, 2012

    [...] más reciente aparición de un intel sysret bug en el sub-sistema de llamadas que los CPUs Intel ejecutan a 64 bits nos demuestra las ventajas de [...]

  16. Security vulnerabilities – the coordinated disclosure sausage mill – blog.xen.org linked to this post on June 19, 2012

    [...] in AMD’s amd64 (aka x86_64) processor architecture. George Dunlap has already explained the technical details. This serious problem was discovered in the context of Xen and FreeBSD on the 9th of April. The fix [...]

  17. US-CERT: Intel CPU Vulnerability « Random Walks linked to this post on June 20, 2012

    [...] 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 [...]

  18. Intel: virtualisatielek is geen gat maar een functie | Tech-nieuws linked to this post on June 20, 2012

    [...] Hat, Suse naast de besturingssystemen FreeBSD en NetBSD plus de open source-virtualisatiesoftware Xen en het cloud-OS van [...]

  19. US-CERT: lỗi nguy hiểm trong chip xử lý Intel | CuocSongSo linked to this post on June 22, 2012

    [...] Lỗ hổng bảo mật này xuất phát từ cách mà các CPU thực hiện xử lý lỗi trong phiên bản của các hướng dẫn SYSRET, vốn là một phần của tiêu chuẩn x84-64 được định nghĩa bởi AMD (Advanced Micro Devices). Hiểu đơn giản, nếu một hệ điều hành được xây dựng dựa theo các tiêu chuẩn của AMD nhưng lại chạy trên phần cứng của Intel, sự khác biệt trong quá trình triển khai hệ thống có thể bị khai thác. Chi tiết về lỗi có thể tham khảo từ website của Xen. [...]

  20. US-CERT: lỗi nguy hiểm trong chip xử lý Intel | Tin tức Việt Nam trong ngày | Tin tức việt Nam và thế giới linked to this post on June 23, 2012

    [...] Lỗ hổng bảo mật này xuất phát từ cách mà các CPU thực hiện xử lý lỗi trong phiên bản của các hướng dẫn SYSRET, vốn là một phần của tiêu chuẩn x84-64 được định nghĩa bởi AMD (Advanced Micro Devices). Hiểu đơn giản, nếu một hệ điều hành được xây dựng dựa theo các tiêu chuẩn của AMD nhưng lại chạy trên phần cứng của Intel, sự khác biệt trong quá trình triển khai hệ thống có thể bị khai thác. Chi tiết về lỗi có thể tham khảo từ website của Xen. [...]

  21. Winners Pwnie Awards 2012 linked to this post on July 26, 2012

    [...] vulnerability uses SYSRET instructions for increasing privileges. Some Other OS is also vulnerable to this [...]

  22. Windows 7 Privilege Escelation & UAC Bypass Guide with SYSRET exploit linked to this post on November 28, 2012

    [...] The Sysret exploit is made possible due to a subtle difference in the way in which Intel processors implement error handling in their version of AMD’s SYSRET instruction. The SYSRET instruction is part of the x86-64 standard defined by AMD. If an operating system is written according to AMD’s spec, but run on Intel hardware, the difference in implementation can be exploited by an attacker to write to arbitrary addresses in the operating system’s memory. Click here for a more detailed description of the Sysret Exploit. [...]

  23. Intel Sysret 本地提权漏洞在WIN7 X64下的实现分析 « 360安全卫士技术博客 linked to this post on December 4, 2012

    [...] 博客小编说:自从今年上半年Intel CPU的sysret指令导致的本地提权漏洞(CVE-2012-0217)被批露之后,这个跨操作系统平台的漏洞就引起了业界的强烈关注,从我们作安全研究角度来说,这个漏洞是足以写入教科书的。xen对于这个漏洞的分析比较完整,后来 VUPEN 放出了这个漏洞在win7 x64平台上的利用分析。 [...]

  24. Intel Processor SYSRET Vulnerability Affecting Some 64-Bit Systems | Threatpost linked to this post on March 25, 2013

    [...] Microsoft Windows 7, FreeBSD, NetBSD and there’s a chance Apple’s OS X may also be vulnerable, according to a blog on Xen.org, an open source community for users of the virtual [...]

You must be logged in to post a comment.