Security experts have discovered new Intel Spectre vulnerabilities
Researchers from ETH Zurich have uncovered a new class of vulnerabilities linked to Intel processors. They were able to bypass Intel's defenses against Spectre.
Spectre is a class of vulnerabilities that was originally identified in 2018, along with Meltdown, a similar exploit that affected AMD chips. These flaws exploited speculative execution, which in turn leaked data. Though the vulnerabilities were patched 7 years ago, Microsoft released a Registry security mitigation a year ago to protect against the vulnerability.
As it turns out, Spectre has resurfaced in a new persona. The researchers from ETH Zurich have labeled the data-leaking flaws as Branch Prediction Race Conditions (BPRC). These vulnerabilities primarily affect Intel CPUs from the 9th generation (Coffee Lake Refresh) down to the 7th generation (Kaby Lake).
The researches said that the branch predictors on Intel processors are updated asynchronously inside the processor pipeline, as a result of which there are potential race conditions. In such a scenario, two or more processes or threads could attempt to access and update the same information concurrently, and this could lead to chaos. They discovered an exploit was possible where a processor switches privilege levels, such as from user to kernel, while branch predictor updates are still in flight. This can lead to a new attack vector, Spectre v2, which allows unauthorized code injection thanks to elevated privileges. The security experts call it Branch Privilege Injection (BPI). These issues affect all sorts of computers, from PCs to servers in data centres.
Here is how the issue was described: “We can use the vulnerability to read the entire contents of the processor’s buffer memory (cache) and the working memory (RAM) of another user of the same CPU.”
The discovery by the Swiss team indicates that there is a performance impact, up to 2.7 percent overhead for the microcode mitigation on Alder Lake, though Intel is yet to comment on this issue.
Intel has released a microcode update to address the new flaw, which has been designated as CVE-2024-45332. The Indirect Branch Predictor Advisory describes the issue as follows: Potential security vulnerabilities in some Intel® Processor indirect branch predictors may allow information disclosure. Intel is releasing microcode updates to mitigate these potential vulnerabilities.
It is worth noting that products from AMD and ARM don't appear to be affected by this new exploit.
Source: The Register, ETH Zurich
Advertisement
John, hyperthreading does not come into play for this one.
That was for the old Meltdown problem, where indeed turning off HT or using a processor without HT capability, e.g. some of the ‘F’ models (which also had no igpu onboard).
Spectre variations are not dependent on that.
From the ETHZ article, all intel CPU in the last 6 years (at least) are affected, meaning inclusive of the non-HT models.
For reference, that means back to ‘coffee lake’ (9xxx) the first generation intel that had a core that was updated to resist meltdown and some of the original spectre attack, without the hideous performance loss from the OS workaround to stop Meltdown.
Turns out they were still cutting corners in the spec-exec logic and not doing proper privilege checking.
The news here is that someone found a new way that gets past the old ‘spectre v2’ mitigations, re-enabling the old problems of faulty branch seperation in the complex mess that is speculative execution.
In this case, the CPUs have faulty branch prediction logic that is exposed in certain conditions, the fault being it does not apply the correct privilege level to the predicted branch until a bit after a privilege level has changed. If you know a bit about “user” code and OS/driver code, you’ll know that switching back and forth happens a LOT.
And that is where the villain comes in and makes deceptive branching to fool it, to do the same things the original spectre exploits did.
Reported leakage rate is 4-5 kilobytes per second. Details on code injection proficiency was not provided.
Hyper-threading was never a great ideal it was only a desperate attempt at finding more performance when Intel couldn’t find it in clock speeds. The mitigations also affected performance at least a little. I think some OS like Chrome OS actually just disabled Hyper-threading by default. Which was probably the correct fix to really mitigate the exposure.
OpenBSD has already disabled hyperthreading. I don’t know why they don’t just use random encrypted keys for each branch prediction, then just throw away the key once they’ve finished?