New Spectre Exploits Beat All Mitigations: Fixes to Severely Degrade Performance
Researchers from two universities have discovered several new variants of Spectre exploits that affect all modern processors from AMD and Intel with micro-op caches. Existing Spectre mitigations do not protect the CPUs against potential attacks that use these vulnerabilities. Meanwhile, researchers believe that mitigating these vulnerabilities will cause more significant performance penalties than the fixes for previous types of Spectre exploits. However, it remains unknown how easy these vulnerabilities are to exploit in the real world, so the danger may be limited to directed attacks.
Three New Types of Potential Spectre Attacks
Scholars from the University of Virginia and University of California San Diego have published a paper describing three new types of potential Spectre attacks using vulnerabilities of micro-op caches (thanks Phoronix for the tip). The team of researchers led by Ashish Venkat discovered that hackers can potentially steal data when a CPU fetches commands from the micro-op cache. Since all modern processors from AMD (since 2017) and Intel (since 2011) use micro-op caches, all of them are prone to a hypothetical attack.
The document lists three new types of potential attacks:
A same thread cross-domain attack that leaks secrets across the user- kernel boundary;
A cross-SMT thread attack that transmits secrets across two SMT threads running on the same physical core, but different logical cores, via the micro-op cache;
Transient execution attacks that have the ability to leak an unauthorized secret accessed along a misspeculated path, even before the transient instruction is dispatched to execution.
Fixes Going to Hurt
Both AMD and Intel had been informed about the vulnerabilities in advance, but so far, no microcode updates or OS patches have been released. In fact, the researchers believe that since potential attacks must use mitigations in extremely low-level caches, it will be impossible to fix the weaknesses without severe performance impacts.
The document describes several ways to mitigate the vulnerabilities.
One of the ways is to flush the micro-op cache at domain crossings, but since modern CPUs need to flush the Instruction Translation Lookaside Buffer (iTLB) to flush the micro-op cache, frequent flushing of both will 'lead to heavy performance consequences, as the processor can make no forward progress until the iTLB refills.'
The second way is to partition micro-op caches based on privileges. However, as the number of protection domains increase, such partitioning would translate into heavy underutilization of the micro-op cache, removing much of its performance advantages.
Yet another way is to implement a performance counter-based monitoring that detects anomalies, but the technique is prone to misclassification errors, whereas frequent probing leads to significant performance degradation.
One thing to keep in mind is that exploiting micro-ops cache vulnerabilities is extremely tricky as such malware will have to bypass all other software and hardware security measures that modern systems have and then execute a very specific type of attack that is unconventional, to say the least. To that end, chances that the new Spectre vulnerabilities will lead to widespread wrongdoings are rather low. Instead, they could be used for specific targeted attacks from sophisticated players, like nation-states
Ah, my friend mitigations=off, here we go again....ID: gwobmgp
one day we'll have 2x performance increase just with this flag…ID: gwoj0fu
Not exactly a new thing that security and accessibility/speed/performance are at opposite ends of the spectrum.
Stuff just needs to be kept in a balance of reasonable risk versus productivity.ID: gwpqido
If this exploit only applied to intel cpus you would be roasted for this comment lol
Yay for Bulldozer I guess.ID: gwplaur
*Cheers in Steamroller*
I haven't read about any demonstration code that shows an exploit in action, but they may be keeping that quiet for now. There also hasn't been too much discussion of how hard an attack would be, hopefully we will get more this week.ID: gwp3aiw
An attack would be hard in almost every realistic scenario since there's too much noise.
But as always the target for these aren't average PCs so realistic scenarios don't necessarily need to apply.ID: gwp6k0f
all of these attacks require another exploit that leaks timing data or physically accessing a computer. this is one of the reasons browser developers were pushed to quickly update their software since they could be exploited remotely. after that it requires building a model that can accurately infer secrets based off cache timing.
imo the biggest danger would be someone finding a simple unpatched browser exploit that leaks timing of every user. otherwise these attacks are not practical at all on a consumer level. generally it will always be exponentially easier to trick someone into loading malware.ID: gwpv5uz
This attack is so specific you would likely need to generate versions of it for each architecture you're attacking. It's a really dense paper and a fantastic read. They outline each step for determining the uOp cache structure (something I've never seen done before), then using that information to create the required functions for the covert channel. In theory you could do that automatically without knowing the victims machine. In reality you'd probably have versions for each to take out the guess work.
It's certainly on the more difficult end of the spectrum for these kind of attacks (most of the numbers seem to be from performance counter metrics). But with that comes a very robust side channel, with potential to leak more information more quickly and with higher accuracy, in a way that would be very hard to detect.
Your right that there's no proof of concept you can just download and run, but I don't see any reason to doubt the validity of their claims. There are some minor issues that could have just been resources available to them. They picked an Intel architecture that's broken in a way that potentially makes their attack easier, and only really cover AMD in two paragraphs just to show variant 2 of their method works. Still worth the read for the architectural insight into the frontend alone.
I don't consider this particularly worrying yet (it was obvious the uOp cache would be attacked eventually), the linux mailing list thread I saw didn't seem too concerned. However, it does open the door to further research/improvements and shows how effective side channels can be when utilizing deep architectural knowledge.
Lets just all be very good peoples and use the honor system and promise to never use these exploits. Problem solved!ID: gwp3v6r
How many RMB were you paid for that post?ID: gwpoayt
Oh sir, you dropped this:
What happens when universities find these exploits for Neuralink brain chips? These kind of exploits seem inevitable for all silicon going forward, while they keep getting more and more complex, so do the ways in which the security of them can be breached. Or at the least.. universities seem better able to find them. A lot of these attacks are hypothetical or need to be under specific circumstances, but even so, it's the fear of them that does more harm than anything. For many years I never even thought about this issue, but these days it feels like you can't go a few months without a new exploit or vulnerability being found. And wondering are you better off with AMD, or Intel.. older CPU, newer CPU etc. Even though it doesn't really effect personal home users that much, it's still not nice to be reading about this stuff all the time.
The only reason I mention this is because the whole world is trending towards depending more and more towards digital data and a dependency on silicon for the world to function.
And if we have a solar flare? Even worse. It's happened before in the last few hundred years. But because it was so long ago, the only thing it affected was the Telegraph systems.
just wake up, beauty?
Are affected Core 2 Duo/Quad or Pentium 4/D with these things?