Monday, May 3rd 2021

New Spectre Vulnerability Version Beats All Mitigations, Performance to Badly Degrade After the Fix

Researches from the University of Virginia and University of California San Diego have published their latest case study. The two universities have worked hard to discover a new Spectre vulnerability variant that can pass all of the existing Spectre mitigations and exploit all of the existing processors coming from Intel and AMD. The vulnerability exploits all of the existing x86 processors, and as it is new, there are not implementations of hardware mitigation. The whitepaper called "I see dead μops" takes the implementation of exploiting micro-op caches that could lead to a potential data leak in the processor, which is leading to a Spectre-type exploit.

Modern x86 processors break down complex instructions into smaller RISC-like units called micro-ops, in the frontend, where it makes the design of the backend part much simpler. The micro-ops are stored in the micro-ops cache. The paper is describing micro-op cache-based timing channel exploits in three primary settings: "a) across code regions within the same thread, but operating at different privilege levels, (b) across different co-located threads running simultaneously on different SMT contexts (logical cores) within the same physical core, and (c) two transient execution attack variants that leverage the micro-op cache to leak transiently accessed secrets, bypassing several existing hardware and software-based mitigations, including Intel's recommended LFENCE."
For more details about the ways of exploiting the data, it is recommended to read the paper in full. However, if you are wondering about the possible mitigations of this exploit, there could be some bad news regarding performance. Both Intel and AMD have been informed about the attack, and the solution is coming our way. However, since the exploit targets a low-level caching structure, a possible solution would take a severe degradation of performance, as believed by researchers. Maybe Intel and AMD find a solution that is not as severe, but rather a modest one. We must wait to find out.
Sources: I See Dead μops Paper, via forum member P4-630 (Thanks for the tip!)
Add your own comment

77 Comments on New Spectre Vulnerability Version Beats All Mitigations, Performance to Badly Degrade After the Fix

#2
GorbazTheDragon
:sleep:

Nothing we haven't seen before... Superscalar out of order with the levels of speculative execution and caching that are enabled by modern processes will always be vulnerable to this kind of attack. Go make a new paradigm if you want to build something that's secure from the ground up, but trust me, you'll lose a lot of performance along the way.
Posted on Reply
#3
mtcn77
AleksandarKsimples.
:confused::fear:
Posted on Reply
#4
Mussels
Moderprator
Siiiiiiiiiiigh.
Posted on Reply
#5
Caring1
So physical access is required to implement any exploit?
Posted on Reply
#6
GorbazTheDragon
Caring1So physical access is required to implement any exploit?
Modern data centers generally work on the assumption that code run on the processor cannot be considered secure. Because of this, one of the biggest vulnerability cases here is the colocated SMT threads on a physical core.
Posted on Reply
#8
1d10t
Spectre V5 now? Wow, HBO or Netflix should make mini series from this.
Posted on Reply
#9
TheinsanegamerN
This requires high level access to execute, which traditional security measures already prevent. This is one of those "if they get this you're already hosed" type situation. I'd be really surprised if the mitigations are required rather then optional patches that can be applied to just mission critical equipment that is most likely to get hit by this.

Although IMO most of this stuff has been wildly overblown, the majority of CPU attacks require a pre pwned system with remote administrator/BIOS access. I can see emergency patches for the remote execution ones, but the rest should be optional IMO.
Posted on Reply
#10
DeathtoGnomes
1d10tSpectre V5 now? Wow, HBO or Netflix should make mini series from this.
AND we have a frog to play the narrator/host!!!

@R-T-B
Posted on Reply
#11
Chrispy_
The whitepaper makes it look like you need to be running fairly complex code in order to exploit this vulnerability.

Perhaps someone cleverer than me can tell me why adding its signature/behaviour to antivirus/antimalware wouldn't solve the issue?
Posted on Reply
#12
R-T-B
GorbazTheDragon:sleep:

Nothing we haven't seen before... Superscalar out of order with the levels of speculative execution and caching that are enabled by modern processes will always be vulnerable to this kind of attack. Go make a new paradigm if you want to build something that's secure from the ground up, but trust me, you'll lose a lot of performance along the way.
This is my line of thought these days.

Hardware security was flawed from the get go, do not trust the machine you run on as a programmer if your data is sensitive. If it is, treat it as such. Otherwise, this'll be an endless uphill battle.
Chrispy_Perhaps someone cleverer than me can tell me why adding its signature/behaviour to antivirus/antimalware wouldn't solve the issue?
Because once the behavior has happened, it's usually too late? The targeted data was already taken.
DeathtoGnomesAND we have a frog to play the narrator/host!!!

@R-T-B
I hate this gameshow.
Posted on Reply
#13
Imsochobo
TheinsanegamerNThis requires high level access to execute, which traditional security measures already prevent. This is one of those "if they get this you're already hosed" type situation. I'd be really surprised if the mitigations are required rather then optional patches that can be applied to just mission critical equipment that is most likely to get hit by this.

Although IMO most of this stuff has been wildly overblown, the majority of CPU attacks require a pre pwned system with remote administrator/BIOS access. I can see emergency patches for the remote execution ones, but the rest should be optional IMO.
a few of the first ones which received mitigations were not overblown at all.
a few are and a few arent, hence we all got reduced performance cause it wasn't overblown.

But all spectre like attacks are not critical
Posted on Reply
#14
qubit
Overclocked quantum bit
Oh hell no.
Posted on Reply
#15
billeman
Well as long as it's possible to disable the mitigation it's okay for me
Posted on Reply
#16
TumbleGeorge
But how fast will work modern PC's if disable any security protocols and pathes?
Posted on Reply
#18
london
like nasa working hard for 6 months to prevent and eventual asteroid impact. result? " its going to hit us hard, and there is notin we can do" geez good work guys, next time just shut the hell up? by !
Posted on Reply
#19
Solaris17
Dainty Moderator
YES!!!

I have been waiting for TPU to pick this up, so I can finally correct the bad reporting, and the terrible assumptions users who cant read make.

Neat take aways from this white paper:

- They only specify "Skylake" but fail to say which rendition of the arch, and its important to note, after initial skylake protection has been built in on an arc level

- They mention "Zen" testing, but not which one. Zen is old and been around awhile, they make a uOP mention with "Zen2" but its just an example.

- They mention ARM in the title and the text, but never actually show testing done with the ARM arc.

People are already questioning the methods used in this work as the flaws mentioned above are a pretty bid deal.

Remember kids, 100% of people that drink water die.
Posted on Reply
#20
Lycanwolfen
To be honest. I think they should stop finding these things. Because when they do the source gets leaked then the new virus's come out. Stop finding holes period and things would not come out. Now adays we hear oh we found a new way to break a system. The weeks later the source is released to public and hackers just suck it up.
Posted on Reply
#21
Mescalamba
Most of these are bit like bird flu craze, only existing in theoretical realm.
Posted on Reply
#22
Hemmingstamp
LycanwolfenTo be honest. I think they should stop finding these things. Because when they do the source gets leaked then the new virus's come out. Stop finding holes period and things would not come out. Now adays we hear oh we found a new way to break a system. The weeks later the source is released to public and hackers just suck it up.
Is it not best to be informed, or would you rather us all wander around in a dark wood?
Posted on Reply
#23
stimpy88
Could this be the reason for all those AMD CPU cancellation rumours lately???
Posted on Reply
#24
Hemmingstamp
stimpy88Could this be the reason for all those AMD CPU cancellation rumours lately???
No.
Posted on Reply
#25
efikkan
GorbazTheDragonNothing we haven't seen before... Superscalar out of order with the levels of speculative execution and caching that are enabled by modern processes will always be vulnerable to this kind of attack.
Actually, there is nothing principally wrong with speculative execution and caching. It's only a matter of making sure all caches are cleaned etc., which will require redesigns of microarchitectures, not just the mitigations we've seen this far which only makes it harder. Getting rid of SMT would help a lot though.

Until this happens, we should expect a stream of new Spectre class exploits.
Caring1So physical access is required to implement any exploit?
Local access is required, as usual. These vulnerabilites are not a real problem for consumers or non-cloud servers, so software mitigations should really be opt-in. There is no reason for all of us to suffer.
TheinsanegamerNThis requires high level access to execute, which traditional security measures already prevent. This is one of those "if they get this you're already hosed" type situation. I'd be really surprised if the mitigations are required rather then optional patches that can be applied to just mission critical equipment that is most likely to get hit by this.
Well, this is exactly why we do security in layers. Sooner or later you should expect a vulnerability in one layer.
The real elephant in the room is the perpetual stupidity of (public) cloud computing, where a vulnerability on any layer can potentially bypass nearly all security measures. Nothing sensitive should ever run in the public cloud, unfortunately it does.
TheinsanegamerNAlthough IMO most of this stuff has been wildly overblown, the majority of CPU attacks require a pre pwned system with remote administrator/BIOS access. I can see emergency patches for the remote execution ones, but the rest should be optional IMO.
Yes. Consumers should not worry about the exploits, only about the mitigations. I wish patches were opt-in.
Chrispy_Perhaps someone cleverer than me can tell me why adding its signature/behavior to antivirus/antimalware wouldn't solve the issue?
Because antimalware don't have the ability to stop any attack, just identify known bad software.
This is why there are endless streams of new virus variants for Windows, until the specific underlying vulnerabilities (/design faults) are resolved.

If you find a vulnerability, you can just make a script that makes thousands of small variants of the program performing the exploit, resulting in different binary signatures, and the cat and mouse game is on. Antimalware doesn't work the way people think, they can never fix an exploit, and it's even debatable whether they do much "good" at all. Having priveleged software like this may even open up new attack vectors, and there are even some antimalware software that can be regarded as malware/spyware itself.
Posted on Reply
Add your own comment