Nearly every AMD CPU since 2017 vulnerable to Inception data-leak attacks
AMD processor users, you have another data-leaking vulnerability to deal with: like Zenbleed, this latest hole can be to steal sensitive data from a running vulnerable machine.
The flaw (CVE-2023-20569), dubbed Inception in reference to the Christopher Nolan flick about manipulating a person’s dreams to achieve a desired outcome in the real world, was disclosed by ETH Zurich academics this week.
And yes, it’s another speculative-execution-based side-channel that malware or a rogue logged-in user can abuse to obtain passwords, secrets, and other data that should be off limits.
Inception utilizes a previously disclosed vulnerability alongside a novel kind of transient execution attack, which the researchers refer to as training in transient execution (TTE), to leak information from an operating system kernel at a rate of 39 bytes per second on vulnerable hardware. In this case, vulnerable systems encompasses pretty much AMD’s entire CPU lineup going back to 2017, including its latest Zen 4 Epyc and Ryzen processors.
Despite the potentially massive blast radius, AMD is downplaying the threat while simultaneously rolling out microcode updates for newer Zen chips to mitigate the risk. “AMD believes this vulnerability is only potentially exploitable locally, such as via downloaded malware,” the biz said in a public disclosure, which ranks Inception “medium” in severity.
Intel processors weren’t found to be vulnerable to Inception, but that doesn’t mean they’re entirely in the clear. Chipzilla is grappling with its own separate side-channel attack disclosed this week called Downfall.
How Inception works
As we understand it, successful exploitation of Inception takes advantage of the fact that in order for modern CPUs to achieve the performance they do, processor cores have to cut corners.
Rather than executing instructions strictly in order, the CPU core attempts to predict which ones will be needed and runs those out of sequence if it can, a technique called speculative execution. If the core guesses incorrectly, it discards or unwinds the computations it shouldn’t have done. That allows the core to continue getting work done without having to wait around for earlier operations to complete. Executing these instructions speculatively is also known as transient execution, and when this happens, a transient window is opened.
Normally, this process renders substantial performance advantages, and refining this process is one of several ways CPU designers eke out instruction-per-clock gains generation after generation. However, as we’ve seen with previous side-channel attacks, like Meltdown and Spectre, speculative execution can be abused to make the core start leaking information it otherwise shouldn’t to observers on the same box.
Inception is a fresh twist on this attack vector, and involves two steps. The first takes advantage of a previously disclosed vulnerability called Phantom execution (CVE-2022-23825) which allows an unprivileged user to trigger a misprediction — basically making the core guess the path of execution incorrectly — to create a transient execution window on demand.
This window serves as a beachhead for a TTE attack. Instead of leaking information from the initial window, the TTE injects new mispredictions, which trigger more future transient windows. This, the researchers explain, causes an overflow in the return stack buffer with an attacker-controlled target.
“The result of this insight is Inception, an attack that leaks arbitrary data from an unprivileged process on all AMD Zen CPUs,” they wrote.
In a video published alongside the disclosure, and included below, the Swiss team demonstrate this attack by leaking the root account hash from /etc/shadow on a Zen 4-based Ryzen 7700X CPU with all Spectre mitigations enabled.
You can find a more thorough explanation of Inception, including the researchers’ methodology in a paper here [PDF]. It was written by Daniël Trujillo, Johannes Wikner, and Kaveh Razavi, of ETH Zurich. They’ve also shared proof-of-concept exploit code here.
Mitigating the risk
According to the uni team, in order to fully mitigate this threat, “the branch predictor state has to be fully flushed while switching between distrusting contexts.” In practice the situation is a bit complex, and this is how we understand it, judging from the Linux kernel patch that addresses Inception:
- You can install a microcode update from AMD (packaged as a BIOS update, see above disclosure) that only protects user processes from other user processes, and virtual machines from other virtual machines, on the same host. Zen 3 and 4 CPU cores need this microcode update; Zen 1 and 2 don’t, according to AMD.
- You can install the microcode update and enable a so-called safe RET feature in the kernel that does the above plus protects the kernel from user processes, and hosts from guest virtual machines. This is the default.
- There are IBPB-level protections you can opt for instead, including one for cloud providers that just protects hosts from guests.
The Linux kernel patch notes, “The mitigation works by ensuring all RET instructions speculate to a controlled location, similar to how speculation is controlled in the retpoline sequence.”
As we said, Zen 3 and 4 CPUs — this includes Epyc 3 and 4 and Ryzen 5000 and 7000 processors — will need a microcode update because they apparently lack hardware support necessary to flush the entire branch predictor state. AMD has already started rolling out these microcode fixes to system makers to distribute to customers to address the vulnerability. The bad news for sysadmins is that this could mean some downtime to apply the microcode BIOS update.
The academics warned of a potentially sizable performance impact, depending on the situation, from these mitigations. The actual hit may well depend on your workload and whether you think it’s worth it, given who uses your systems and what they run on them.
In a statement to The Register, AMD said “any performance impact will vary depending on workload and system configuration, but AMD expects performance impacts from the microcode patch or BIOS update to be minimal. For Linux performance … we’re still assessing that mitigation.”
So our advice: get the microcode upgrade, if necessary, and install a patched Linux kernel, and see how it fares. If you’re not using Linux, badger your OS maker about it, or check for updates at least.
Last month, we learned of Zenbleed, which can be exploited by rogue users and malware to steal passwords, cryptographic keys, and other secrets on older AMD Zen 2-based systems. While narrower in scope, Zenbleed is potentially more dangerous due to its ease of deployment. ®
Bootnote
Speaking of AMD, this week another Zen 1 processor bug was addressed with a Linux kernel patch: this time, “under certain circumstances, an integer division by 0 which faults, can leave stale quotient data from a previous division operation on Zen 1 microarchitectures.”
Yes, a divide-by-zero fault can end up leaking some value.
READ MORE HERE