{"id":19925,"date":"2022-08-16T20:34:34","date_gmt":"2022-08-16T16:34:34","guid":{"rendered":"https:\/\/me-en.kaspersky.com\/blog\/retbleed-vulnerability\/19925\/"},"modified":"2022-08-16T20:34:47","modified_gmt":"2022-08-16T16:34:47","slug":"retbleed-vulnerability","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/retbleed-vulnerability\/19925\/","title":{"rendered":"Retbleed attack, or Spectre strikes back"},"content":{"rendered":"

In mid-July, researchers at the Swiss Federal Institute of Technology, Zurich, published<\/a> 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> \u2013 a defense method against a certain type of Spectre attack. Essentially, the authors showed that its program-compilation technique \u2013 previously thought to be effective protection against a so-called Spectre Variant 2 attack \u2013 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\u2019s start with some background information.\n<\/p>\n

What is Spectre v2? Let\u2019s talk about branch prediction<\/h2>\n

\nMore than four years ago, in early 2018, two research papers describing<\/a> 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<\/a> 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\u2019s default functionality called \u201cbranch prediction\u201d for the attack.<\/p>\n

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 \u2013 denied.<\/p>\n

The processor can perform billions of such operations per second, and while a certain condition is being checked, it\u2019s often idle (loosely speaking \u2013 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.<\/p>\n

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.<\/p>\n

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\u2019t have access to. Yes, these calculations are then discarded, but their result (the highly sensitive data) is temporarily stored in the cache \u2013 from where it can be stolen.<\/p>\n

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\u2019 jargon, this is known as a \u201cgadget\u201d. 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 \u2013 no more than tens of bits per second \u2013 by side-channel reading.<\/p>\n

Let\u2019s try to put it even simpler. The processor\u2019s built-in branch prediction system doesn\u2019t separate instructions from different programs, and a single program can be used to make the processor speculatively execute an instruction it\u2019s not supposed to run. Previously, this didn\u2019t appear to be a problem, as software cannot directly access data in the processor\u2019s 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.<\/p>\n

Hang on. Spectre was discovered in 2018. Surely they\u2019ve patched it by now?<\/h2>\n

\nIt\u2019s not that easy with hardware vulnerabilities. First and foremost, even from this simplified description, it\u2019s clear that the vulnerability, though definitely hardware-based, requires certain conditions in the software to coincide for it to be exploited. If that\u2019s the case, why not just patch the software? That\u2019s much easier to do than upgrading hardware. It\u2019s 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.<\/p>\n

There\u2019s another question that\u2019s extremely important in the context of Retbleed research. What would be the cost of a software or hardware patch? Every single method of \u201cclosing\u201d 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\u2019s research showing<\/a> that a diverse set of patches for Spectre in a system led to a performance decrease of up to 25%.<\/p>\n

And here comes Retpoline<\/a>, 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\u2019t 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.<\/p>\n

What did the Retbleed study show?<\/h2>\n

\nBasically, this fresh research has shown that Retpoline\u2026 doesn\u2019t 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:<\/p>\n

\n