Daniel Gruss

The ZombieLoad attack exploits a vulnerability of most Intel CPUs, which allows leaking data currently processed by other programs. ZombieLoad is extremely powerful, as it leaks data from user-processes, the kernel, secure enclaves, and even across virtual machines. Moreover, ZombieLoad also works on CPUs where Meltdown is fixed in software or hardware.

The Meltdown attack published in 2018 was a hardware vulnerability which showed that the security guarantees of modern CPUs do not always hold. Meltdown allowed attackers to leak arbitrary memory by exploiting the lazy fault handling of Intel CPUs which continue transient execution with data received from faulting loads. With software mitigations, such as stronger kernel isolation, as well as new CPUs with this vulnerability fixed, Meltdown seemed to be solved. In this talk, we show that this is not true, and Meltdown is still an issue on modern CPUs. We present ZombieLoad, an attack closely related to the original Meltdown attack, which leaks data across multiple privilege boundaries: processes, kernel, SGX, hyperthreads, and even across virtual machines. Furthermore, we compare ZombieLoad to other microarchitectural data-sampling (MDS) attacks, such as Fallout and RIDL. The ZombieLoad attack can be mounted from any unprivileged application, without user interactions, both on Linux and Windows. In the talk, we present multiple attacks, such as monitoring the browsing behavior, stealing cryptographic keys, and leaking the root-password hash on Linux. In a live demo, we demonstrate that such attacks are not only feasible but also relatively easy to mount, and difficult to mitigate. We show that Meltdown mitigations do not affect ZombieLoad, and consequently outline challenges for future research on Meltdown attacks and mitigations. Finally, we discuss the short-term and long-term implications of Meltdown attacks for hardware vendors, software vendors, and users.

Other people: Michael Schwarz Moritz Lipp

We present the next step after Rowhammer, a new software-based fault attack primitive: Plundervolt (CVE-2019-11157). Many processors (including the widespread Intel Core series) expose privileged software interfaces to dynamically regulate processor frequency and operating voltage. We show that these privileged interfaces can be reliably exploited to undermine the system's security. In multiple case studies, we show how the induced faults in enclave computations can be leveraged in real-world attacks to recover keys from cryptographic algorithms (including the AES-NI instruction set extension) or to induce memory safety vulnerabilities into bug-free enclave code.

Fault attacks pose a substantial threat to the security of our modern systems, allowing to break cryptographic algorithms or to obtain root privileges on a system. Fortunately, fault attacks have always required local physical access to the system. This changed with the Rowhammer attack (BlackHat USA 2015, CCC 2015), which for the first time enabled an attacker to mount a software-based fault attack. However, as countermeasures against Rowhammer are developed and deployed, fault attacks require local physical access again. In this CCC talk, we present the next step, a long-awaited alternative to Rowhammer, a second software-based fault attack primitive: Plundervolt. Dynamic frequency and voltage scaling features have been introduced to manage ever-growing heat and power consumption in modern processors. Design restrictions ensure frequency and voltage are adjusted as a pair, based on the current load, because for each frequency there is only a certain voltage range where the processor can operate correctly. For this purpose, many processors (including the widespread Intel Core series) expose privileged software interfaces to dynamically regulate processor frequency and operating voltage. In this talk, we show that these privileged interfaces can be reliably exploited to undermine the system's security. We present the Plundervolt attack, in which a privileged software adversary abuses an undocumented Intel Core voltage scaling interface to corrupt the integrity of Intel SGX enclave computations. Plundervolt carefully controls the processor's supply voltage during an enclave computation, inducing predictable faults within the processor package. Consequently, even Intel SGX's memory encryption/authentication technology cannot protect against Plundervolt. In multiple case studies, we show how the induced faults in enclave computations can be leveraged in real-world attacks to recover keys from cryptographic algorithms (including the AES-NI instruction set extension) or to induce memory safety vulnerabilities into bug-free enclave code. We finally discuss why mitigating Plundervolt is not trivial, requiring trusted computing base recovery through microcode updates or hardware changes. We have responsibly disclosed our findings to Intel on June 7, 2019. Intel assigned CVE-2019-11157 to track this vulnerability and refer to mitigations. The scientific paper on Plundervolt will appear at the IEEE Security & Privacy Symposium 2020. The work is the result of a collaboration of Kit Murdock (The University of Birmingham, UK), David Oswald (The University of Birmingham, UK), Flavio D. Garcia (The University of Birmingham, UK), Jo Van Bulck (imec-DistriNet, KU Leuven, Belgium), Daniel Gruss (Graz University of Technology, Austria), and Frank Piessens (imec-DistriNet, KU Leuven, Belgium).

Other people: Kit Murdock

With the beginning of last year, two major security vulnerabilities have been disclosed: Meltdown and Spectre. While mitigations in software and hardware have been rolled out right away, new variants have been continuously released in the following months. With all those confusing names, how can you possibly still have a clear overview of all those vulnerabilities (SpectreV1, SpectreV2, Meltdown, Spectre-NG, SpectreRSB, L1TF, Foreshadow, ...)? With this talk, we present a novel classification that will ease the naming complexity of the current jungle of variants. Along with all different attacks, we will give an overview of all proposed mitigations and show how an attacker still can mount an attack despite the presence of implemented countermeasures. Furthermore, we will present new variants of the Meltdown attack, exploiting different parts of the CPU.

Only a few days after the Chaos Communication Congress closed its doors last year, two major security vulnerabilities have been disclosed to the public. Meltdown and Spectre exploit critical vulnerabilities in modern processors, allowing attackers to read arbitrary data currently processed on the computer without any permissions or privileges. While mitigations in software and hardware have been proposed and rolled out right away, new variants of Spectre and Meltdown attacks have been published frequently in the following months. Spectre v1? Spectre v2? Meltdown? Spectre-NG? SpectreRSB? L1TF? Foreshadow? - With all those names and variants, how can you possibly have still a clear overview of those vulnerabilities? With all those operating systems, compiler, and microcode updates, is my system really protected? In our talk, we present a novel classification of Spectre and Meltdown attacks and propose a new naming scheme to ease the naming complexity of the current jungle of variants. Furthermore, we give an overview of all proposed mitigations and show that an attacker can still mount an attack despite the presence of implemented countermeasures. Finally, we show new variants of the Meltdown attack, exploiting different parts of the CPU.

Other people: Moritz Lipp Michael Schwarz Claudio Canella

"Insanity: doing the same thing over and over again and expecting different results." Albert Einstein - Who did not live long enough to see Rowhammer Recent studies have found that repeated accesses to DRAM rows can cause random bit flips, resulting in the so called Rowhammer vulnerability. We present Rowhammer.js, the first remote software-induced hardware-fault attack, from JavaScript. We also extend our presentation with an overview of cache side-channel attacks, that use the same technique to evict data from the cache.

Last year, studies demonstrated Rowhammer, a fault attack that can cause random bit flips by repeatedly accessing DRAM rows. This vulnerability has already been exploited to gain root privileges and to evade a sandbox, showing the severity of faulting single bits for security. However, these exploits are written in native code and use special instructions that flush data from the cache. In this talk we present Rowhammer.js [1], a JavaScript-based implementation of the Rowhammer attack. After presenting the native attack, we underline the challenges we faced to trigger the vulnerability from JavaScript, without any special instruction. Beyond DRAM, this attack also requires a very fine understanding of CPU cache internals, that are largely undocumented. We detail our findings on these undocumented parts, and the different steps that led to the attack from JavaScript. We also give an outlook on possible exploits, including gaining root privileges from JavaScript and performing fault attacks on cryptography. In the last part, we extend our presentation with an overview of cache attacks, bridging the gap between hardware-fault attacks and side channels. In side-channel attacks, the attacker doesn't rely on a direct software compromise, but rather on passive observation of hardware characteristics when a victim process runs. In common with Rowhammer.js, these attacks use techniques to evict data from the last-level cache. [1] Daniel Gruss, Clémentine Maurice, Stefan Mangard. Rowhammer.js: A Remote Software-Induced Fault Attack in JavaScript. http://arxiv.org/abs/1507.06955

Other people: Clémentine Maurice