Given their vital importance for governments and enterprises around the world, we need to trust public clouds to provide strong security guarantees even in the face of advanced attacks and hardware vulnerabilities. While transient execution vulnerabilities, such as Spectre, have been in the spotlight since 2018, until now there have been no reports of realistic attacks on real-world clouds, leading to an assumption that such attacks are not practical in noisy real-world settings and without knowledge about the (host or guest) victim. In particular, given that today's clouds have large fleets of older CPUs that lack comprehensive, in-silicon fixes to a variety of transient execution vulnerabilities, the question arises whether sufficient software-based defenses have been deployed to stop realistic attacks---especially those using older, supposedly mitigated vulnerabilities. In this paper, we answer this question in the negative. We show that the practice of mitigating vulnerabilities in isolation, without removing the root cause, leaves systems vulnerable. By combining such mitigated'' (and by themselves harmless) vulnerabilities, attackers may still craft an end-to-end attack that is more than the sum of its parts. In particular, we show that attackers can use L1TF, one of the oldest known transient execution vulnerabilities (discovered in January 2018), in combination with a simple speculative out-of-bounds load, to leak data from other guests in a commercial cloud computing platform. Moreover, with an average end-to-end duration of 15 hours to leak the TLS key of an Nginx server in a victim VM under noisy conditions, without detailed knowledge of either host or guest, the attack is realistic even in one of today's biggest and most important commercial clouds.

Despite nearly a decade of mitigation efforts by both industry and academia, the community has yet to find comprehensive and efficient countermeasures against pernicious hardware vulnerabilities such as Spectre and Rowhammer. While Spectre mitigations have mostly focused on patching dangerous disclosure gadgets in high-value codebases such as the Linux kernel, mitigating Rowhammer in software is still challenging and security often hinges on the (im)practicality of real-world attacks. Indeed, some Rowhammer attacks are entirely nondeterministic, triggering random bit flips in the hope of corrupting victim data-but at the risk of corrupting critical data and crashing the system. More reliable attacks rely on techniques such as memory templating and massaging, but achieving fully deterministic behavior is still difficult in face of complex memory management abstractions in both hardware and software. In this paper, we show that fully deterministic Rowhammer attacks are feasible. To this end, we exploit synergies with Spectre and specifically focus our attention on so-called half-Spectre gadgets. We show these gadgets, previously deemed unexploitable on last-generation CPUs due to their inability to directly disclose secret data, do enable powerful disclosure primitives to harden other attacks such as Rowhammer. Specifically, we use half-Spectre gadgets to build Preload+Time, a generic primitive to monitor a controlled victim's physical memory activity at the cache line granularity, without sharing memory with the victim. We use this capability to craft ProbeHammer, the first crash-free end-to-end Rowhammer exploit that does not rely on templating or massaging. In detail, we spray physical memory with aggressor (i.e., user) and victim (i.e., page table) data and disclose their location with Preload+Time. This primitive allows us to select safe hammering patterns and avoid unintended bit flips that may crash the system. Our evaluation confirms ProbeHammer attacks yield no false positives (hence, no crashes) by construction and can compromise real-world systems in a matter of hours.

Linear Address Masking (LAM) is a recently announced Intel feature that enables the CPU to mask off some upper bits before dereferencing a 64-bit pointer. The key idea behind LAM (as well as the similar Upper Address Ignore or UAI from AMD), is to allow software to efficiently make use of untranslated bits of 64-bit linear addresses for metadata. The assumption is that, with LAM (or UAI) features enabled, one can implement fast security (e.g., memory safety) checks and ultimately improve security of production systems.In this paper, we challenge this assumption and show that LAM features can actually degrade security in production by dramatically increasing the Spectre attack surface. To support this claim, we present a new Spectre covert channel based on noncanonical address translation and address key challenges to implement it in practice. For instance, we exploit properties of modern TLBs to craft a reliable signal and LAM features to (crucially) bypass canonicality checks. Moreover, we show that, unlike classic Spectre covert channels, ours unlocks generic (or unmasked) Spectre gadgets encoding high-entropy secrets as dereferenced pointers. Unlike classic (or masked) gadgets, we show the latter escape deployed mitigations and are pervasive in high-value targets such as the Linux kernel. To showcase the new attack surface, we present an end-to-end exploit for Spectre based on LAM (SLAM) targeting upcoming Intel CPUs. We specifically focus on the BHI Spectre variant and show that, despite mitigations believed to eradicate the attack surface, our exploit can abuse a variety of gadgets in the latest Linux kernel and leak the root password hash within minutes from kernel memory. We conclude by evaluating mitigations.

Since the Spectre and Meltdown disclosure in 2018, the list of new transient execution vulnerabilities that abuse the shared nature of microarchitectural resources on CPU cores has been growing rapidly. In response, vendors keep deploying “spot” (per-variant) mitigations, which have become increasingly costly when combined against all the attacks—especially on older-generation processors. Indeed, some are so expensive that system administrators may not deploy them at all. Worse still, spot mitigations can only address known (N-day) attacks as they do not tackle the underlying problem: different security domains that run simultaneously on the same physical CPU cores and share their microarchitectural resources.