Moritz Lipp

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 Daniel Gruss

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: Michael Schwarz Daniel Gruss Claudio Canella

Hardware is often considered as an abstract layer that behaves correctly, just executing instructions and outputting a result. However, the internal state of the hardware leaks information about the programs that are executing. In this talk, we focus on how to extract information from the execution of simple x86 instructions that do not require any privileges. Beyond classical cache-based side-channel attacks, we demonstrate how to perform cache attacks without a single memory access, as well as how to bypass kernel ASLR. This talk does not require any knowledge about assembly. We promise.

When hunting for bugs, the focus is mostly on the software layer. On the other hand, hardware is often considered as an abstract layer that behaves correctly, just executing instructions and outputing a result. However, the internal state of the hardware leaks information about the programs that are running. Unlike software bugs, these bugs are not easy to patch on current hardware, and manufacturers are also reluctant to fix them in future generations, as they are tightly tied with performance optimizations. In this talk, we focus on how to extract information from the execution of simple x86 instructions that do not require any privileges. The most studied microarchitectural attacks are beyond doubt cache attacks. Indeed, the timing of a memory access depends heavily on the state of the CPU cache. But beyond memory accesses that are the base of classical cache-based side-channel attacks, other x86 instructions leak information about the internal state of the hardware, and thus about running programs. First, we present side channels caused by the "clflush" instruction, that flushes all content of the cache. We will explain how it can be used to perform side-channel attacks that are faster and stealthier than their classical counterpart, without performing so much as a single memory access [1]. Second, we present side channels caused by the prefetch instructions. We will explain how these instructions can be used to translate virtual addresses to physical addresses - without the use of the proc interface that is restricted today -, and to bypass kernel ASLR [2]. This talk does not require any knowledge about assembly. We promise. The talk will be given as a joint presentation by Clémentine Maurice and Moritz Lipp. [1] Daniel Gruss, Clémentine Maurice, Klaus Wagner and Stefan Mangard, "Flush+Flush: A Fast and Stealthy Cache Attack", DIMVA 2016 [2] Daniel Gruss, Clémentine Maurice, Anders Fogh, Moritz Lipp, Stefan Mangard, "Prefetch Side-Channel Attacks: Bypassing SMAP and Kernel ASLR", CCS 2016

Other people: Clémentine Maurice