• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

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

AleksandarK

News Editor
Staff member
Joined
Aug 19, 2017
Messages
3,233 (1.12/day)
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.

View at TechPowerUp Main Site
 
: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.
 
So physical access is required to implement any exploit?
 
So 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.
 
olivetti_lettera.jpg


Return to monke
 
Spectre V5 now? Wow, HBO or Netflix should make mini series from this.
 
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.
 
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?
 
: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.

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.

AND we have a frog to play the narrator/host!!!

@R-T-B
I hate this gameshow.
 
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.

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
 
But how fast will work modern PC's if disable any security protocols and pathes?
 
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 !
 
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.
 
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.
 
Most of these are bit like bird flu craze, only existing in theoretical realm.
 
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.
Is it not best to be informed, or would you rather us all wander around in a dark wood?
 
Could this be the reason for all those AMD CPU cancellation rumours lately???
 
Back
Top