Older AMD, Intel chips vulnerable to data-leaking ‘Retbleed’ Spectre variant
Older AMD and Intel chips are vulnerable to yet another Spectre-based speculative-execution attack that exposes secrets within kernel memory despite defenses already in place. Mitigating this side channel is expected to take a toll on performance.
ETH Zurich computer scientists Johannes Wikner and Kaveh Razavi have dubbed the attack Retbleed, which they describe as an addition to the family of speculative-execution flaws known as Spectre-BTI (variant 2) that can be exploited by branch target injection.
That’s a way to abuse a processor’s indirect branch predictors to manipulate which operations get speculatively executed after a near indirect branch instruction. Doing so – training the indirect branch predictor – allows an attacker to infer data values that should be kept secret.
In short, rogue software on a machine can exploit Retbleed to obtain from memory it shouldn’t have access to – such as operating system kernel data – passwords, keys, and other secrets. As with all the Spectre flaws, and offshoots like Hertzbleed, if malware really wants to steal data, there are usually plenty of vulnerabilities in OSes and applications to do just that, or ways of socially engineering the user, without having to manipulate the host processor.
That said, if nothing’s done about Spectre et al, maybe one day someone will exploit it in the wild in a meaningful way. Also, if you’re running virtual machines in a public cloud, you may want to be aware of this security weakness as information about or in your VM could leak to another customer via Retbleed. Data can be obtained from kernel memory at about a quarter of a kilobyte a second on affected Intel processors, and about four kilobytes a second on vulnerable AMD silicon.
“Unlike its siblings, who trigger harmful branch target speculation by exploiting indirect jumps or calls, Retbleed exploits return instructions,” explained Wikner and Razavi in a draft blog post about the design bug provided to The Register. “This means a great deal, since it undermines some of our current Spectre-BTI defenses.”
The defenses against Spectre-BTI include kernel page-table isolation (KPTI), retpoline, user pointer sanitization, and disabling unprivileged eBPF.
Retpoline works by replacing indirect branch instructions (eg, JMP with the destination address in a register) with subroutine return instructions (eg, RET after pushing the address onto the stack). Since Retbleed relies on return instructions, it effectively bypasses retpoline.
Retbleed is the result of research into the way a processor’s branch predictor unit behaves with indirect branches. What Wikner and Razavi found, as explained in their paper [PDF], Retbleed: Arbitrary Speculative Code Execution with Return Instructions, is that “all return instructions that follow sufficiently deep call stacks can be hijacked using a precise branch history on Intel CPUs.”
And on AMD processors, they found “that any return instruction can be hijacked, regardless of the previous call stack, as long as the previous branch destination is correctly chosen during branch poisoning.”
During the course of their Retbleed investigation, Wikner, Razavi, and another ETH Zurich researcher Daniël Trujillo, discovered that AMD CPU cores perform phantom jumps (JMPs): these are branch predictions being made without a branch instruction actually present.
“By training the branch predictor to believe there exists a branch at a particular location, we therefore trigger a speculative branch, even in the absence of an architectural branch,” the three researchers explain in a Retbleed addendum. “This allows speculative execution of code originating from arbitrary instruction boundaries, commonly known as phantom branches.”
AMD Zen 1, Zen 1+ and Zen 2 were found to be affected by phantom jumps. The boffins say phantom jumps expand the attack surface of Retbleed but are more difficult to exploit because “the secret data needs to already be available in a register in the architectural path.”
The technique’s severity is somewhat reduced by the fact that it applies to older silicon: AMD CPU family 0x15 through 0x17 (the most recent of which shipped April 2021) or an Intel Core generation 6 through 8 (the most recent of which shipped Q3 2019).
But in an email to The Register, Wikner and Razavi said some of the affected chips are of fairly recent vintage.
“Zen 3 has only been available for a bit more than a year, so all the AMD chips bought before that are vulnerable,” they said. “In fact, the latest AMD Zen 2 was released last year. We don’t know the exact percentage in deployment, but we imagine it will be a significant fraction of AMD CPUs in production given that servers have a lifetime of 3-5 years usually.
“As for Skylake-based CPUs, this is harder to tell since they are a few years old now. Newer Intel CPUs up to Alder Lake also suffer from Retbleed through BHI, another vulnerability that was disclosed earlier in the year, but exploitation is harder.”
Both Intel and AMD have improved more recent chip architectures to make these sorts of attacks more difficult.
“For Intel, the default-on eIBRS mitigation on newer CPUs makes it much harder to hijack a kernel return instruction,” said Wikner and Razavi. “For AMD, it’s difficult to say, but Zen 3 seems to be much more careful about queuing speculative memory loads. This is likely due to a broader effort by AMD to address speculative execution attacks.”
Wikner analyzed the virtual machine instances offered by Amazon Elastic Compute Cloud (Amazon EC2) and Google Compute Engine (GCE) and believes quite a few are affected. On EC2, likely vulnerable instances include: Mac x86 (Coffee Lake), T3 (Intel Xeon Platinum 8000 series processor, Skylake-SP or Cascade Lake), T3a (AMD EPYC 7000), M5 (Intel Xeon Platinum 8175M Skylake), and M5a (AMD EPYC 7000).
And among GCE, likely vulnerable instances include: N1, N2D, T2D, E2, C2D, M1, and N1+GPU.
The researchers have posted a video of Retbleed in action, which consists of four exciting minutes of command-line output and a pleasant enough electronic score.
Unfortunately, the fixes may hinder performance significantly.
“Retbleed’s patch overhead is going to between 13 percent and 39 percent,” said Wikner and Razavi. “Mitigating Phantom JMPs has 106 percent overhead (ie, 2 times slower).”
The researchers said they expect the Linux kernel team will be releasing patches for both Intel and AMD, as will hypervisor makers such as Xen. “Intel will enable IBRS by default and there are complementary efforts underway to mitigate Retbleed without IBRS,” they said.
Retbleed has been designated CVE-2022-29900 for AMD, and CVE-2022-29901 and CVE-2022-28693 for Intel. AMD is also using CVE-2022-23816 and CVE-2022-23825 to track Retbleed, which it calls a branch type confusion.
A spokesperson for Intel told The Register: “Intel worked with our industry mitigation partners, the Linux community and virtual-machine manager vendors to make mitigations available to customers.”
The spokesperson also said Microsoft’s OS is already protected: “Windows systems are not affected as they already have these mitigations by default.” That mitigation, we’re told, is IBRS, aka Indirect Branch Restricted Speculation protection.
The x86 giant said it will share a summary of the vulnerabilities here and a technical advisory here.
Intel added it wasn’t aware of any active exploitation outside of the lab.
At noon Pacific Time today, AMD is due to publish a white paper on its analysis of Retbleed and technical guidance for programmers to ensure their code isn’t vulnerable to side-channel attack. You can find a copy here [PDF] in the meantime.
A spokesperson for the chip designer told us: “As part of its ongoing work to identify and respond to new potential security vulnerabilities, AMD is recommending software suppliers consider taking additional steps to help guard against Spectre-like attacks. That guidance is available in a new AMD whitepaper available today.”
In short, deploy the latest OS updates and processor microcode to ensure you have adequate defenses against Retbleed, and if you’re a developer, particularly a kernel programmer, check the technical guidance from Intel and AMD to prevent shipping exploitable privileged code.
Wikner, Razavi et al have published a summary and FAQ here, and the source code for their project is here.
As to the seriousness of it all? “Install the latest operating system updates. If you have secrets on virtual machines with shared hardware (eg, in the cloud), you should be aware of the issue. But it’s not good for your health to worry too much,” the team wrote. ®
READ MORE HERE