In the continued effort to achieve as much speed as possible from our CPUs, “speculative execution” features have been incorporated into design. Speculative execution is a technique intended to eke out performance gains by executing code that might not be on the path of a program when conditionals have been resolved. Unfortunately, that trick for speeding up the CPU comes at a fairly steep price — the potential compromise of sensitive information. First came Spectre, then Meltdown, then RIDL. And now we have “Retbleed,” which overcomes the “Retpoline” mitigation developed by Google:
What is “Retbleed?” And what does this new attack mean for those that require their digital information to be secure (and, come on, who of us does not)?
What Is Retbleed?
Retbleed is a branch type confusion attack on the speculative execution mechanism of modern CPUs. Speculative Execution is employed by modern CPUs to improve performance by executing code along a predicted path for a branch condition, and discarding the results if the prediction is wrong. If the prediction is right (which happens more often than not), the speculative execution of a given code path ensures that the CPU is not waiting uselessly for the results of an execution.
An analogy might help here. Let’s assume that you are tasked by your significant other to run some errands, so you head to your car and resolve yourself to helping — even though you really want to catch up on the latest episode of Obi-Wan Kenobe on Disney+. The kicker here is that you are not told exactly what errands you need to run — you are going to receive the directions via text messages while you are out and about. You could sit in your car and await the next errand, but being the impatient person that you are, you apply your best estimation of the errands that need to be run, and you make a decision to start heading to the appropriate store. For example, you remembered that you needed milk and eggs, so you start driving to the grocery store. Sure enough, 3 minutes into the drive to the store you receive a text message to go pick up groceries. Look at that — you just saved 3 minutes by starting the drive to the store even before you knew that was the destination.  If you had been wrong, you might have to backtrack a bit to go the proper destination for the errand, but as long as you are right most of the time, you can make it back to your comfy chair and Disney+ faster.
What you were doing was “speculative execution.” You started down the path of a predicted decision before that decision was actually resolved. This happens in CPUs because it takes a few cycles for branch conditions to be resolved (think of all those “if” statements in code), but most of the time the execution path is the same (think of all those iterations of a loop, where each of the iterations executes the loop code except the very last decision). So the CPU can improve performance by properly predicting paths of execution based upon conditionals, and executing those in advance. If wrong, the CPU discards the results.
However, this speculative execution results in changes to the state of the CPU. Memory is accessed, cache lines are evicted or loaded, call stacks are altered, and so on. The result of these side-effects of speculative execution is that sensitive information can be leaked via side-channels, through clever use of this knowledge and cleverly crafted code that manipulates the speculative execution in a particular way.
How Does Retbleed Affect Information Security?
Retbleed is another in a series of CPU attacks, like Spectre and Meltdown, which use a deeply embedded CPU architecture performance feature to leak information through side channels. This attack can leak kernel memory at an alarming rate and accuracy (912 Bytes per second on Intel, a whopping 3.92 KB per second on AMD). Kernel information is the most sensitive type, including passwords and cryptographic keys. Worse yet, Kernel memory sits underneath virtualization layers — so shared systems like Virtual Machines and Containers can leak information across boundaries. For example, attacks on the CPU originating in one virtual compute node in a Cloud Computing environment might leak information from another virtual machine provisioned for a different customer. Here’s more information about the Retbleed attack from Bleeping Computer.
With sensitive information like passwords and encryption keys at risk, it is imperative that organizations follow Retbleed closely and apply patches provided by their vendors. Continue to be vigilant on potential data breaches, and keep good cryptography hygiene such as encryption both in transit and at rest, high strength cryptographic algorithms and key materials, secure storage of keys, and encryption of data at rest.  None of these, alone, will secure you against the perilous risk that Retbleed poses; however, it provides a defense-in-depth best practice that can mitigate the problems both now and in the future.
Intel is working with the Linux community to develop a fix, but as of this writing no patch as been announced or released.
Security vs. Performance
This is yet another example of our society’s unquenchable thirst for speed. We want our web browsers to work faster, our file transfers to fly like the wind, and cryptographic operations to be transparent to our user experience. Our demands for speed and intolerance for even the slightest delay puts the economic pressure on chip manufacturers to drive better and better performance out of chips. Techniques like speculative execution and branch prediction are unquestionably brilliant and undeniably aid in performance. By some estimates, if we were to do away with these features altogether, we can expect a significant performance degradation in our CPU’s (20% or more). But we all need to evaluate our priorities — I doubt that any legitimate organization would be willing to forego the protection of sensitive information in order to gain a 20% performance improvement in cryptographic operations. So, please, let us all continue to push for Information Security first and foremost, and be more tolerant of minor performance impediments along the way.
Have any questions? Contact us at https://www.coviantsoftware.com/contact/
