“Meltdown: Reading Kernel Memory from User Space – Lessons learned from Meltdown’s exploitation of the weaknesses in today’s processors”
Communications of the ACM,
Contributed Articles
By
This article presents Meltdown, a novel attack that exploits a vulnerability in the way the processor enforces memory isolation.
Memory isolation is a cornerstone security feature in the construction of every modern computer system. Allowing the simultaneous execution of multiple mutually distrusting applications at the same time on the same hardware, it is the basis of enabling secure execution of multiple processes on the same machine or in the cloud. The operating system is in charge of enforcing this isolation, as well as isolating its own kernel memory regions from other users.
Given its central role on modern processors, the isolation between the kernel and user processes is backed by the hardware, in the form of a supervisor bit that determines whether code in the current context can access memory pages of the kernel. The basic idea is that this bit is set only when entering kernel code and it is cleared when switching to user processes. This hardware feature allows operating systems to map the kernel into the address space of every process, thus supporting very efficient transitions from the user process to the kernel (for example, for interrupt handling) while maintaining the security of the kernel memory space.
This article presents Meltdown, a novel attack that exploits a vulnerability in the way the processor enforces memory isolation.
Root cause. At a high level, the root cause of Meltdown’s simplicity and strength are side effects caused by out-of-order execution, which is an important performance feature of modern processors designed to overcome latencies of busy execution units (for example, a memory fetch unit waiting for data arrival from memory). Rather than stalling the execution, modern processors run operations out-of-order, that is, they look ahead and schedule subsequent operations on available execution units of the core.
While this feature is beneficial for performance, from a security perspective, one observation is particularly significant. Some CPUs allow an unprivileged process to load data from a privileged (kernel or physical) address into a temporary register, delaying exception handling to later stages. The CPU even allows performing further computations based on this register value, such as using it as an index to an array access. When the CPU finally realizes the error, it reverts the results of this incorrect transient execution, discarding any modifications to the program state (for example, registers). However, we observe that out-of-order memory lookups influence the internal state of the processor, which in turn can be detected by the program. As a result, an attacker can dump the entire kernel memory by reading privileged memory in an out-of-order execution stream, and subsequently transmitting the data via a covert channel, for example, by modulating the state of the cache. As the CPU’s internal state is not fully reverted, the receiving end of the covert channel can later recover the transmitted value, for example, by probing the state of the cache.
Threat model. To mount Meltdown, the adversary needs the ability to execute code on a vulnerable machine. Executing code can be achieved through various means, including hosting in cloud services, apps in mobile phones, and JavaScript code in website. Vulnerable machines include personal computers and servers featuring a large range of processors (see the accompanying table). Furthermore, while countermeasures have been introduced to both operating systems and browsers, these only became available after the disclosure of Meltdown.
Impact. Three properties of Meltdown combine to have a devastating effect on the security of affected systems. First, exploiting a hardware vulnerability means the attack does not depend on specific vulnerabilities in the software. Thus, the attack is generic and, at the time of discovery, affected all existing versions of all major operating systems. Second, because the attack only depends on the hardware, traditional software-based protections, such as cryptography, operating system authorization mechanisms, or antivirus software, are powerless to stop the attack. Last, because the vulnerability is in the hardware, fixing the vulnerability requires replacing the hardware. While software-based countermeasures for Meltdown have been developed, these basically avoid using the vulnerable hardware feature, incurring a significant performance hit.
Evaluation. We evaluated the attack on modern desktop machines and laptops, as well as servers and clouds. Meltdown is effective against all major operating systems (including Linux, Android, OS X and Windows), allowing an unprivileged attacker to dump large parts of the physical memory. As the physical memory is shared among all other tenants running on the same hardware, this may include the physical memory of other processes, the kernel, and in the case of paravirtualization, the memory of the hypervisor or other co-located instances. While the performance heavily depends on the specific machine—for example, processor speed, TLB and cache sizes, and DRAM speed—we can dump arbitrary kernel and physical memory at a speed of 3.2KiB/s to 503KiB/s.
Countermeasures. While not originally intended to be a countermeasure for Meltdown, KAISER, developed initially to prevent side-channel attacks targeting KASLR, also protects against Meltdown. Our evaluation shows that KAISER prevents Meltdown to a large extent. Consequently, we stress it is of utmost importance to deploy KAISER on all operating systems immediately. Fortunately, during the responsible disclosure window, the three major operating systems (Windows, Linux, and OS X) implemented variants of KAISER and recently rolled out these patches.
Spectre attacks and follow-up works. Meltdown was published simultaneously with the Spectre Attack, which exploits a different CPU performance feature, called speculative execution, to leak confidential information. Meltdown is distinct from Spectre in several ways, notably that Spectre requires tailoring to the victim process’s software environment but applies more broadly to CPUs and is not mitigated by KAISER. Since the publication of Meltdown and Spectre, several prominent follow-up works exploited out of order and speculative execution mechanisms to leak information across other security domains. See Canella et al. for a survey.
At the time of writing, Microarchitectural Data Sampling (MDS) is the most recent line of attacks, which exploit speculative and out-of-order execution in order to leak information across nearly all possible security domains. Finally, while some of the attacks discussed in this section have been mitigated, additional work is required to mitigate others as well as future yet-to-be discovered CPU vulnerabilities.
About the Authors:
Moritz Lipp is a Ph.D. candidate at Graz University of Technology, Flanders, Austria.
Michael Schwarz is a postdoctoral researcher at Graz University of Technology, Flanders, Austria.
Daniel Gruss is an assistant professor at Graz University of Technology, Flanders, Austria.
Thomas Prescher is a chief architect at Cyberus Technology GmbH, Dresden, Germany.
Werner Haas is the Chief Technology Officer at Cyberus Technology GmbH, Dresden, Germany.
Jann Horn is a member of Project Zero at Google Project Zero, Zurich, Switzerland.
Stefan Mangard is a professor at Graz University of Technology, Flanders, Austria.
Paul Kocher is an entrepreneur and researcher focused on cryptography and data security, San Francisco, CA, USA.
Daniel Genkin is an assistant professor at the University of Michigan, Ann Arbor, MI, USA.
Yuval Yarom is a senior lecturer at the University of Adelaide and Data61, South Australia.
Mike Hamburg is a researcher in the Cryptography Research Division of Rambus, Sunnyvale, CA, USA.
Raoul Strackx is a senior engineer at Fortanix, Flanders, Belgium.
See also:
- Meltdown (security vulnerability) – Wikipedia
- Spectre (security vulnerability) – Wikipedia
- USENIX Security ’18 – Meltdown: Reading Kernel Memory from User Space – September 18, 2018
USENIX Security ’18 – Meltdown: Reading Kernel Memory from User Space – September 18, 2018
Moritz Lipp – Graz University of Technology – Abstract: The security of computer systems fundamentally relies on memory isolation, e.g., kernel address ranges are marked as non-accessible and are protected from user access. In this paper, we present Meltdown. Meltdown exploits side effects of out-of-order execution on modern processors to read arbitrary kernel-memory locations including personal data and passwords. Out-of-order execution is an indispensable performance feature and present in a wide range of modern processors. The attack is independent of the operating system, and it does not rely on any software vulnerabilities. Meltdown breaks all security guarantees provided by address space isolation as well as paravirtualized environments and, thus, every security mechanism building upon this foundation. On affected systems, Meltdown enables an adversary to read memory of other processes or virtual machines in the cloud without any permissions or privileges, affecting millions of customers and virtually every user of a personal computer. We show that the KAISER defense mechanism for KASLR has the important (but inadvertent) side effect of impeding Meltdown. We stress that KAISER must be deployed immediately to prevent large-scale exploitation of this severe information leakage.
