The discovery of Spectre and Meltdown in 2017 marked the first instances of “transient execution vulnerabilities”. These are vulnerabilities in the internal design of CPUs (their “microarchitecture”), which attackers may abuse to steal data. Examples may include one smartphone app stealing data from other apps or the operating system, or a website stealing data from another website open in the same browser.
After eight years of research, the security community is still doubtful to what extent these transient execution vulnerabilities pose serious security threats in real-world scenarios. Understanding the nature and root cause of these vulnerabilities requires expert knowledge of computer architecture and (low-level) software. Moreover, exploiting these vulnerabilities requires very advanced techniques, involving side-channel analysis, branch mispredictions, and microarchitectural state massaging. Successful exploitation only leads to slow and unreliable data leakage. And lastly, these attacks only apply to limited scenarios, as the attacker needs to share the physical device (CPU) with its victim. So how threatening are these CPU vulnerabilities really?
This project, called “Rain”, showcases the danger posed by transient execution vulnerabilities in a fully realistic, real-world setting. Namely, we show anyone can rent compute resources on commercial clouds such as AWS or Google Cloud, and launch transient execution attacks to leak data their are not supposed to see. In particular, on Google Cloud we manage to find and leak highly sensitive cryptographic data from other customers in a matter of hours.
The Exploit: “L1TF Reloaded”
Our exploit, called “L1TF Reloaded”, combines two long-known transient execution vulnerabilities, L1TF and (Half-)Spectre, to let the cloud rain data. In Internet years, they are both ancient. Researchers disclosed Spectre to the public and L1TF to Intel on the 3rd of January, 2018.
The L1TF vulnerability has long since been mitigated. On older processors, this is done by means of “spot mitigations” in software that prevent the attacks, but do not remove the root cause. Similarly, Spectre has been mitigated using a combination of hardware and software tricks, but again without eliminating the root causes. Spectre attacks are made possible by the presence of specific snippets of code, known as Spectre gadgets, in the victim software. Today’s developers of kernels and hypervisors carefully analyze and, where necessary, fix` such snippets to prevent abuse. However, in our work we do not need a full Spectre gadget, but only a partial one. Since these “Half-Spectre” gadgets are considered not very dangerous by themselves, they are still very common.
We demonstrated the practicality of L1TF Reloaded on KVM-based cloud solutions. Below is a fast-forwarded recording of L1TF Reloaded running on Google Cloud, leaking (1) which other customers are running together with us on the same cloud infrastructure, (2) what programs they are running, and, as an example, (3) leaking the cryptographic key of a webserver (fully compromising that website’s security).
Tell Me More!
For more details, we refer you to our S&P’26 paper:
Rain: Transiently Leaking Data from Public Clouds Using Old Vulnerabilities
We also wrote the bit more informal “Project Rain: L1TF Reloaded Blog” post together with Google about the attack. And AWS published a blog post of their own about our attack.