Researchers discover yet another spectre-related vulnerability attacking Intel's and AMD's Micro-Op Caches.

[orcv]

Summary

Researchers from the University of Virginia's School of Engineering and their collaborators, lead by Ashish Venkat, have found yet another vulnerability affecting current x86 proecessors.

In contrast to vulnerabilities discovered before, defense mechanism against this new exploit would bring a much bigger performance hit, as these attacks steal information when the processor fetches commands from it's micro-op-cache, which occurs much earlier in the execution that with other vulnerabilities

Due to the nature of this exploit, it can get around currently develeoped Spectre defenses like Intel's LFENCE.

 

Quotes

Quote

"Think about a hypothetical airport security scenario where TSA lets you in without checking your boarding pass because (1) it is fast and efficient, and (2) you will be checked for your boarding pass at the gate anyway," Venkat said. "A computer processor does something similar. It predicts that the check will pass and could let instructions into the pipeline. Ultimately, if the prediction is incorrect, it will throw those instructions out of the pipeline, but this might be too late because those instructions could leave side-effects while waiting in the pipeline that an attacker could later exploit to infer secrets such as a password."

Quote

Because all current Spectre defenses protect the processor in a later stage of speculative execution, they are useless in the face of Venkat's team's new attacks. Two variants of the attacks the team discovered can steal speculatively accessed information from Intel and AMD processors.

Quote

"Intel's suggested defense against Spectre, which is called LFENCE, places sensitive code in a waiting area until the security checks are executed, and only then is the sensitive code allowed to execute," Venkat said. "But it turns out the walls of this waiting area have ears, which our attack exploits. We show how an attacker can smuggle secrets through the micro-op cache by using it as a covert channel."

 

My thoughts

This once again shows that individuals and corporations alike put too much trust into a few megacorporations, as they have no other choice.

How much this matters though vastly depends on what your threat model is - the US Government funds Venkat's research as in criticial infrastructure and military applications is where such vulnerabilities matter, while the Average End User is giving up their data to Google, Apple and Facebook for free anyways.

Maybe the seemingly endless stream of vulnerabilities will at some point lead to more investment into open-source architectures like RISC-V, though I will remain highly sceptical of such advancement.

 

Sources

News Article: https://techxplore.com/news/2021-04-scientists-vulnerability-affecting-globally.html

Scientific Paper: https://www.nsf.gov/pubs/2019/nsf19598/nsf19598.htm

[Oshino Shinobu]

Oh this sounds fun. Getting everything protected against Spectre and Meltdown took ages last time, looking forward to arranging it all for a second time around.

[Arika]

Humans have created technology so complex that no one can possibly understand how they work to a degree where there will never be vulnerabilities. 

[Zodiark1593]

6 minutes ago, Arika S said:

Humans have created technology so complex that no one can possibly understand how they work to a degree where there will never be vulnerabilities. 

Even as far back as 2000, different teams took on different design aspects of a cpu core (decoders, pipeline components, cache and memory interfaces, branch prediction, etc). I don’t think there are many people, even among highly skilled architects, that can understand the entirety of a modern, high performance CPU core. 
 

Citing Race for a New Game Machine by David Shippey

[StDragon]

So far, the only sure way to mitigate all forms of Spectre is to disable hyperthreading. If the same mitigation holds true for this form, I think it's the final nail in the coffin for this feature.

 

If the above statement is true, then I expect a plateau in thread count for a generation or two as HT is disabled while physical core count increases. But on the bright side, it's not so bad of a move because we now have chips with more physical cores than most could really need anyways. So there is a silver lining in all this.

[WolframaticAlpha]

21 minutes ago, StDragon said:

So far, the only sure way to mitigate all forms of Spectre is to disable hyperthreading. If the same mitigation holds true for this form, I think it's the final nail in the coffin for this feature.

 

If the above statement is true, then I expect a plateau in thread count for a generation or two as HT is disabled while physical core count increases. But on the bright side, it's not so bad of a move because we now have chips with more physical cores than most could really need anyways. So there is a silver lining in all this.

yOu DoN't NeEd mOrE tHaN 4 c0rEs vro

 

 

 

[tikker]

Since I'm not that deeply versed in what goes on in the depths of CPUs, I realise that because it's now known attackers surely will find a way to exploit it in reality, but to what extent do these vulnerabilities pose an actual threat compared to being a technical feat of doing it? Like what could we compromise or obtain by exploiting this?

[AMD A10-9600P]

4 hours ago, WolframaticAlpha said:

yOu DoN't NeEd mOrE tHaN 4 c0rEs vro

 

 

 

In fairness, for the majority of consumers right now this holds true. Sure, more cores is always nicer, but while the average user running Chrome, Word, PowerPoint, and maybe a bit of Minecraft will benefit from more cores, 4 cores can still very happily power those workloads with no slowdown. If you're solely gaming then it's a different story, and 6 or more cores is optimum, but for your average Joe working from home or browsing the web, they could even get away with a more recent hyperthreaded dual core.

[DuckDodgers]

On 5/1/2021 at 7:14 PM, StDragon said:

So far, the only sure way to mitigate all forms of Spectre is to disable hyperthreading. If the same mitigation holds true for this form, I think it's the final nail in the coffin for this feature.

 

If the above statement is true, then I expect a plateau in thread count for a generation or two as HT is disabled while physical core count increases. But on the bright side, it's not so bad of a move because we now have chips with more physical cores than most could really need anyways. So there is a silver lining in all this.

Another solution is to implement "vertical" multi-threading, where only one thread is active at a time and the CPU only switches to another one if there's a performance bottleneck, like long running memory operation or cache miss. It won't be much benchmark friendly, but it will still benefit the real workloads, minus all the security exploits. This is how multi-threading is implemented in Itanium and IBM's POWER.

[Mark Kaine]

On 5/1/2021 at 11:25 PM, AMD A10-9600P said:

In fairness, for the majority of consumers right now this holds true. Sure, more cores is always nicer, but while the average user running Chrome, Word, PowerPoint, and maybe a bit of Minecraft will benefit from more cores, 4 cores can still very happily power those workloads with no slowdown

Rip, Capcom players

 

(tbf, we really dont need MT if we have 10, 12, 20 etc core gaming cpus, right?)

58 minutes ago, DuckDodgers said:

This is how multi-threading is implemented in Itanium and IBM's POWER.

And, that helps? (i have literally no idea how these exploits are connected to MT)

 

On 5/1/2021 at 11:18 PM, tikker said:

Like what could we compromise or obtain by exploiting this?

its in the OP, same as usual:

On 5/1/2021 at 11:15 AM, orcv said:

an attacker could later exploit to infer secrets such as a password."

 

[StDragon]

1 hour ago, Mark Kaine said:

And, that helps? (i have literally no idea how these exploits are connected to MT)

HT only works because of speculative execution. It's the snooping in on that speculative execution process which inherently makes HT so unsecure.

 

Essentially, it's a fundamentally flawed concept (not design) that all attempts to mitigate against Spectre are bolt-on solutions. It's a game of Whac-a-mole. The only sure way to mitigate against Spectre is to disable speculative execution; that means losing HT. 

[Mark Kaine]

6 minutes ago, StDragon said:

HT only works because of speculative execution. It's the snooping in on that speculative execution process which inherently makes HT so unsecure.

Ok, i see , i knew it is related, also because intel stopped doing HT on most of their lineup for a while , but not how…

 

So only thing i don't understand still, doesn't the computer have to be already compromised for that?  i mean, how where and why would you let random people / programs (attackers) read your cpu , umm, "instructions" ?  Maybe its not that complicated to remotely compromise a computer. But if thats so ,any keylogger would do the same basically.

[igormp]

On 5/1/2021 at 6:15 AM, orcv said:

Maybe the seemingly endless stream of vulnerabilities will at some point lead to more investment into open-source architectures like RISC-V

RISC-V is an open ISA, the archs that are based on it do not need to be open.

[StDragon]

2 hours ago, Mark Kaine said:

So only thing i don't understand still, doesn't the computer have to be already compromised for that?  i mean, how where and why would you let random people / programs (attackers) read your cpu , umm, "instructions" ? 

This is true. But the real worry is that if malware is coded to exploit the CPU, it could in theory (stressing "theory") access credentials from memory.

 

The real worry is with VM infrastructure. Say you have someone with a personal VM running on the same physical hypervisor that another unrelated tenet is. If their VM gets hacked, in theory, it could snoop in on the memory of another VM on the same box; because they're all sharing the same physical CPU. This is why VMWare strongly recommends disabling HT in BIOS for ESXi.

[dilpickle]

Meh. These type of CPU exploits are pretty low on the priority list for most people.

 

There are hundreds of labs around the world that do nothing but search for security flaws in every possible system so these type of finds are kinda boring.

[Spindel]

On 5/1/2021 at 6:14 PM, StDragon said:

So far, the only sure way to mitigate all forms of Spectre is to disable hyperthreading. If the same mitigation holds true for this form, I think it's the final nail in the coffin for this feature.

 

If the above statement is true, then I expect a plateau in thread count for a generation or two as HT is disabled while physical core count increases. But on the bright side, it's not so bad of a move because we now have chips with more physical cores than most could really need anyways. So there is a silver lining in all this.

The downside is that if the world stick to x86 HT is a great way to use as much of the CPU as possible, disabling makes a x86 more inefficient. 

In a world without HT (or SMT or what ever you want to call it) the most efficient way is to change architecture for one that doesn't really leave that much "spare capacity" on the table. 

[DuckDodgers]

13 hours ago, Mark Kaine said:

And, that helps? (i have literally no idea how these exploits are connected to MT)

Any concurrently shared resource between multiple threads is a potential vector for a side-channel attack of this type. HT/SMT is all about sharing common resources, so any buffer/cache is exploitable to variable degree. The ultimate solution is a deep re-design of key elements in the underlying architecture.

[Mark Kaine]

1 hour ago, Nacht said:

Time for SMTor HT to be toggle able on the fly and to only enable during heavy loads that justify it.

yeah, but wouldn't that still be vulnerable, just less often?

 

This is a really complicated matter, but so far to my understanding x86 should be replaced with something more efficient thats more safe. Easier said than done i guess.

[Zodiark1593]

1 hour ago, Nacht said:

 

Add api while at it as well that disables SMT / HT when secure data is handled by that core and force all secure data on 1 core for stuff like browsers as example.

Browsers sets quite speed sensitive and are actually pretty multithreaded. We’d be taking some steps backwards here. 

[StDragon]

3 hours ago, Nacht said:

Time for SMTor HT to be toggle able on the fly and to only enable during heavy loads that justify it.

Dynamic thread allocation won't help. If you had malware running instructing the OS to enable HT based on load, the exploit would have already occurred by the time HT is disabled again.

 

It would be trivial for malware to tease out the resource needed to complete the exploit.

 

[StDragon]

1 hour ago, Nacht said:

 

Add api while at it as well that disables SMT / HT when secure data is handled by that core and force all secure data on 1 core for stuff like browsers as example.

 

47 minutes ago, Zodiark1593 said:

Browsers sets quite speed sensitive and are actually pretty multithreaded. We’d be taking some steps backwards here. 

 

The issue with running JS in a browser was one of timing resolution that could be used to snoop the CPU. This has largely been mitigated as of 2018.

https://www.mozilla.org/en-US/security/advisories/mfsa2018-01/

 

"Jann Horn of Google Project Zero Security reported that speculative execution performed by modern CPUs could leak information through a timing side-channel attack. Microsoft Vulnerability Research extended this attack to browser JavaScript engines and demonstrated that code on a malicious web page could read data from other web sites (violating the same-origin policy) or private data from the browser itself.

 

Since this new class of attacks involves measuring precise time intervals, as a partial, short-term, mitigation we are disabling or reducing the precision of several time sources in Firefox. The precision of performance.now() has been reduced from 5μs to 20μs, and the SharedArrayBuffer feature has been disabled because it can be used to construct a high-resolution timer."

 

[Arika]

2 minutes ago, Nacht said:

Just lock the core SMT / HT to ignore calls while its handling secure data then clear when its done at which point exploit would return with no data.

But what is telling it to disable SMT/HT? If we're at a point where a CPU can be exploited through it's speculative execution, then instructions can be spoofed into making data not look like it's "secure" and run it as normal.

[WereCatf]

5 minutes ago, Arika S said:

But what is telling it to disable SMT/HT? If we're at a point where a CPU can be exploited through it's speculative execution, then instructions can be spoofed into making data not look like it's "secure" and run it as normal.

That's not how it works. These are side-channel attacks that allow for reading of data, they don't allow you to modify data, let alone do privilege-escalation. You'd need to be able to modify the CPU's internal tables in order to change the security-bits on them.

[Arika]

3 minutes ago, WereCatf said:

That's not how it works. These are side-channel attacks that allow for reading of data, they don't allow you to modify data, let alone do privilege-escalation. You'd need to be able to modify the CPU's internal tables in order to change the security-bits on them.

But something would need to be telling the CPU what is "secure data" or not so it knows to disable SMT/HT. if the instructions going into the CPU are marked as being "non-secure data" (since i'm responding to a theory on have to solve these attacks), then the CPU doesn't know to disable SMT/HT and therefore the data is still vulnerable to normal side-channel.

 

What ever is the adjudicator of what data is secure or not is then the weakest link in the chain and liable to be broken.

[WereCatf]

Just now, Arika S said:

But something would need to be telling the CPU what is "secure data" or not so it knows to disable SMT/HT.

Yes, that's the job of the application that has such secure data. The application would typically call an OS API, which would then set up the page-tables accordingly.

1 minute ago, Arika S said:

if the instructions going into the CPU are marked as being "non-secure data" (since i'm responding to a theory on have to solve these attacks),

That would, again, require the attacker to be in a position of altering another process's code and, if they are in such a position, then it'd be pointless, since they could already access that data directly!