vulnerabilities
In mid-July, researchers at the Swiss Federal Institute of Technology, Zurich, published a study describing a new attack that exploits vulnerabilities (or, if you prefer, features) in modern processors. The attack was dubbed Retbleed, and it derived from Retpoline – a defense method against a certain type of Spectre attack. Essentially, the authors showed that its program-compilation technique – previously thought to be effective protection against a so-called Spectre Variant 2 attack – either works only occasionally or not at all. The research, like all previous work on hardware vulnerabilities in processors, is rather complex. In this article, we will, as usual, try not to dive deep into the maze of relevant scientific papers, but to describe the results in simple words. Let’s start with some background information.
What is Spectre v2? Let’s talk about branch prediction
More than four years ago, in early 2018, two research papers describing the Spectre and Meltdown vulnerabilities were published. These are hardware vulnerabilities: a potential data theft attack is made possible by the way processors work. Since then, several more variants of Spectre have been discovered. Researchers have found more ways to attack a common class of vulnerabilities; that is, to use the processor’s default functionality called “branch prediction” for the attack.
Branch prediction and speculative execution of instructions help improve processor performance significantly. In any program, execution of further steps often depends on the result of previous calculations. The simplest example is when a user enters a password to access some secret data. If the password is correct, the data is shown to the user. If the password is wrong, the user is prompted to try again. At the level of simple instructions for the CPU, this translates roughly into checking access rights to certain data in the RAM: if the necessary rights are confirmed, access to the data is granted; if not – denied.
The processor can perform billions of such operations per second, and while a certain condition is being checked, it’s often idle (loosely speaking – waiting for a user to enter a password, or for access rights to be checked). But what if we have it use this idle time to perform the calculations that happen after the most probable result of the check in advance? By the time our hypothetical user enters their hypothetical password, the calculation result will be ready, and the user will see their secret data a little faster.
But how do you know which part of your code is most likely to be executed? From statistics related to previous executions of similar instructions, of course. If our user (please note, this is a highly theoretical and extremely simplified example) enters the correct password nine times out of 10, we can prepare their secret data in advance. If the password is incorrect, we just discard the results and take a little more time to display an error message.
The authors of the 2018 paper described two variants of the Spectre attack, and Variant 2 (also known as Branch Target Injection) trains a branch predictor so that it performs the instructions we need, as in reading data that the attacker shouldn’t have access to. Yes, these calculations are then discarded, but their result (the highly sensitive data) is temporarily stored in the cache – from where it can be stolen.
This is an extremely complex attack. Firstly, the attacker has to be able to execute code on the system under attack, albeit without the desired privileges, i.e., without access to sensitive data. For example, a user could be persuaded to open a web page containing a malicious script in their browser. Secondly, the attacker needs software on the target system that includes code suitable for the attack. In the researchers’ jargon, this is known as a “gadget”. The attack code trains the branch prediction system to speculatively execute this gadget. This causes it to access an area of memory inaccessible to the attacker. The secret data is placed in the CPU cache, from where it can be extracted very slowly – no more than tens of bits per second – by side-channel reading.
Let’s try to put it even simpler. The processor’s built-in branch prediction system doesn’t separate instructions from different programs, and a single program can be used to make the processor speculatively execute an instruction it’s not supposed to run. Previously, this didn’t appear to be a problem, as software cannot directly access data in the processor’s cache in any case. But, as it turns out, by reading side-channels (which is a very complex mechanism: reconstructing data based only on information about the speed of responses to read requests), the data can be extracted.
Hang on. Spectre was discovered in 2018. Surely they’ve patched it by now?
It’s not that easy with hardware vulnerabilities. First and foremost, even from this simplified description, it’s clear that the vulnerability, though definitely hardware-based, requires certain conditions in the software to coincide for it to be exploited. If that’s the case, why not just patch the software? That’s much easier to do than upgrading hardware. It’s also possible to partially fix the vulnerability in the processors through microcode updates. But a definitive solution to the problem can only be found in the release of new processors with modified hardware. Old ones in the meantime remain fully or partially vulnerable.
There’s another question that’s extremely important in the context of Retbleed research. What would be the cost of a software or hardware patch? Every single method of “closing” Spectre reduces performance. For example, the fairly obvious Indirect Branch Restricted Speculation (IBRS) system introduces additional permission checks during speculative code execution and prevents low-privilege programs from accessing highly sensitive data, making a Spectre attack impossible. But with hundreds of thousands or millions of such checks, CPU performance is bound to dip. How far? There’s research showing that a diverse set of patches for Spectre in a system led to a performance decrease of up to 25%.
And here comes Retpoline, a relatively simple protection method against Spectre proposed by Google engineers and used during software compilation. As suggested by the authors of the method, replacing some instructions in typical branching situations with others doesn’t affect software operability, while it does make a Spectre attack impossible. An important advantage of Retpoline over IBRS and other protection methods is just a slight degradation of no more than 5% of performance.
What did the Retbleed study show?
Basically, this fresh research has shown that Retpoline… doesn’t work! The return instructions that the Retpoline method relied on could also be exploited in a slightly modified scheme to trick (or maliciously train) the branch predictor. The authors have even recorded a video demonstrating the attack:
A Retbleed attack demo on a Linux-based system.
The video shows how a hashed super-user password is stolen by a program that doesn’t have access to such data. Note that the video is highly accelerated: in real-time, the password theft on an Intel-based system takes a good hour-and-a-half! The results are summarized in the following table:
Summary list of processors tested for Retbleed attack possibility with Retpoline protection activated. Source.
As the table shows, not entirely new, but rather up-to-date AMD Zen 1 and Zen 2 (2017–2019) and Intel’s Kaby Lake and Coffee Lake (2016–2017) processors are prone to a Retbleed attack. On the more modern AMD Zen 3 processors, as well as Intel Alder Lake and the earlier 9th generation processors, a Retbleed attack doesn’t work. This is also due to implementation of Enhanced IBRS hardware protection in Intel processors.
Cost of protection
If a Spectre attack is so difficult to perform, why defend against it at all? Indeed, in order to tailor Spectre to a real-world case (with real damage to the victim), many conditions need to be met: being able to execute code on the attacked system, having attack-prone software installed, and reliably pulling data from the cache (with a certain chance of reading with errors). We previously wrote that the most realistic attack was simulated in a Chrome browser where a potential attacker could, for example, extract saved passwords from the RAM. But this was resolved with a simple protection enhancement in the browser itself, just as with any other trivial bug.
There’s a probability that incremental progress in researching Spectre-like vulnerabilities someday will unexpectedly lead to the possibility of a mass attack on users’ computers and servers. But when it comes to truly sensitive data, Spectre must be taken into consideration now.
The most obvious scenario is an attack through hosting and distributed computing providers. A typical virtual server that you can rent for a reasonable sum from a random provider is essentially a program that runs beside other customers’ virtual OSs on the same high-powered server. A virtual server subscriber can, by definition, run programs on it, but has no privileges to access its neighbors or the host, i.e., the controlling operating system. The separation of virtual environments and the inability to escape from your virtual space is a key security requirement for such service providers.
At the same time, service providers are interested in having as many virtual systems running on the same server as possible without them causing problems for each other. This is the key to the earliest payback on expensive hardware. That said, all Spectre patches (that actually work) reduce performance, and therefore reduce ISP revenue. But providers can’t ignore the problem either, because successfully stealing sensitive data doesn’t even leave a trace!
So when Retpoline was proposed, many grabbed at it like a lifeline to fight the new scourge. But, by January 2018, there were doubts about how reliable this method of defense was. A discussion on a Linux kernel developers’ mailing list shows a number of complaints about Retpoline (the author is unflattering about other methods as well). At the same time, Linus Torvalds, the creator and main custodian of Linux, made clear (in his typical sharp manner) that Retpoline is generally sufficient.
The authors of Retbleed highlight Torvalds on his being judgmental by placing his categorical quote at the beginning of the paper. They also calculated the “cost” of real-world protection for vulnerable processors that cannot be fixed at the hardware level. Patches in the Linux kernel have resulted in performance drops of up to 39% for Intel processors and 14% for AMD processors.
AMD processors turned out to be vulnerable in their own way, and the researchers discovered a phenomenon they called “Phantom JMPs”. It turned out that, under certain conditions, it’s possible to make a branch prediction system execute an arbitrary instruction even if it’s not there in the code under attack. Because of this, the authors had to release a brief one-page addendum to the study. They stipulate, however, that exploiting this vulnerability to do real damage is even more difficult than with traditional Spectre V2.
What now?
For ordinary users, the threat of Spectre attacks remains entirely virtual. Preventive patches from operating-system developers will suffice. In Windows, by the way, effective IBRS protection is enabled by default. New Linux kernel patches will possibly lead to performance degradation, which may be most noticeable in business solutions where computer hardware is squeezed to the limits.
The problem is compounded by the fact that there are many Spectre variants. Retbleed could also be considered a separate variant, which works differently on processors from different manufacturers. AMD and Intel have acknowledged Retbleed as a separate vulnerability and will possibly come up with some hardware solution for it. Corporations will move to new hardware where protective measures are implemented, finding a balance between performance and security. Unfortunately, all software patches have the biggest impact on the performance of relatively old processors. Not only does software become more demanding over time, but there’s also this “penalty” on speculative execution.
If you look at the problem from a bird’s-eye view, this is nothing new. Developers offer a performance-enhancing solution without thinking about security. Sooner or later (later in this case: speculative execution started in the mid-1990s), it comes back to haunt everyone, and security measures have their cost, but eventually new solutions are found, and the hi-tech industry moves on.
The surprise was the discovery of the problem in the hardware: it’s not as easy to fix as in software. And this isn’t a simple bug, but rather a poor (from the security perspective) approach adopted by the industry many years ago. Let’s hope that processor developers come up with new methods for safe and powerful computing before the black swan of an extremely dangerous hardware attack flies over us — one that threatens everyone, is widely known about, and can only be solved by replacing hardware completely.
Tips