New Spectre Exploits Beat All Mitigations: Fixes to Severely Degrade Performance

Intel
(Image credit: Intel)

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. 

Low Risk?

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. 

Anton Shilov
Contributing Writer

Anton Shilov is a contributing writer at Tom’s Hardware. Over the past couple of decades, he has covered everything from CPUs and GPUs to supercomputers and from modern process technologies and latest fab tools to high-tech industry trends.

  • InvalidError
    AFAIK, all of the previous attacks never went beyond proof-of-concept in a curated lab environment optimized for the best chances of success possible and would be next to impossible to pull off in a real-world environment where typical systems have a bunch of background activity raising the background noise level too much for these to be practical. They are hypotheticals to keep in mind just in case for absolutely mission-critical high-stakes secrecy/privacy (no unknown code should be allowed anywhere near those machines) and attempt to mitigate in future designs.

    As usual, you need to get the code on the machine before it can attempt to exploit these flaws in the first place, so the security has already been compromised in some other less sophisticated way before the attempt can ever begin. For normal people and most businesses, this is another non-issue.
    Reply
  • aetolouee
    I wonder if these exploits can be fixed in next gen CPUs without hurting the performance.
    Reply
  • USAFRet
    InvalidError said:
    AFAIK, all of the previous attacks never went beyond proof-of-concept in a curated lab environment optimized for the best chances of success possible and would be next to impossible to pull off in a real-world environment where typical systems have a bunch of background activity raising the background noise level too much for these to be practical. They are hypotheticals to keep in mind just in case for absolutely mission-critical high-stakes secrecy/privacy (no unknown code should be allowed anywhere near those machines) and attempt to mitigate in future designs.

    As usual, you need to get the code on the machine before it can attempt to exploit these flaws in the first place, so the security has already been compromised in some other less sophisticated way before the attempt can ever begin. For normal people and most businesses, this is another non-issue.
    There is/was one, but only 3 years later.
    https://therecord.media/first-fully-weaponized-spectre-exploit-discovered-online/
    Of course, mitigated and fixed by all the intervening patches. So only a potential concern if you are one of those people who purposely negate updates.
    Reply
  • hannibal
    aetolouee said:
    I wonder if these exploits can be fixed in next gen CPUs without hurting the performance.

    most likely yes, but there will be performansseja cost and it seems any prediction can be weakness, so there would be permanentti reduction in the possible speed that can be get, without making these changes.
    Some fixes that were mentioned can be done hardware level, but those are tasks that cpu without those don`t have to do aka you lose power to something that is purely there for security. Server chips most likely will get those in anyway. Do the consumer chips also… lets see… again…
    Reply
  • hotaru.hino
    Even though they've only tested on Zen and Skylake, if the fundamental flaw is with how to use micro-ops caching, then ARM processors may be affected as well. Wikichip claims the A77 has a micro-ops cache.

    Also please note that the ISA has nothing to do with this. It's just how the processors are implemented.
    Reply
  • InvalidError
    hotaru.hino said:
    Even though they've only tested on Zen and Skylake, if the fundamental flaw is with how to use micro-ops caching, then ARM processors may be affected as well. Wikichip claims the A77 has a micro-ops cache.
    The inevitable outcome of practically all CPUs being built around the same fundamental principles since there is a limited number of sensible ways to do things regardless of ISA. Everyone tries to do things their own way because patents force them to do so and they end up converging on the nearly exact same solutions 15-20 years later once the patents (ex.: Intel's Netburst uOP cache / replay queue) have expired.
    Reply
  • mac_angel
    InvalidError said:
    AFAIK, all of the previous attacks never went beyond proof-of-concept in a curated lab environment optimized for the best chances of success possible and would be next to impossible to pull off in a real-world environment where typical systems have a bunch of background activity raising the background noise level too much for these to be practical. They are hypotheticals to keep in mind just in case for absolutely mission-critical high-stakes secrecy/privacy (no unknown code should be allowed anywhere near those machines) and attempt to mitigate in future designs.

    As usual, you need to get the code on the machine before it can attempt to exploit these flaws in the first place, so the security has already been compromised in some other less sophisticated way before the attempt can ever begin. For normal people and most businesses, this is another non-issue.
    yea, I was wondering the same. I remembered all these security issues hitting the news, but even then I was really wondering how much my home computers would really be at risk. And all the 'fixes' did say there would be something of a performance hit, also made me think that these fixes should be options for people. State that they are security fixes for ... and let people decide if they think it's really necessary for a computer that is mostly used for playing games on Steam.
    Reply
  • hotaru.hino
    mac_angel said:
    yea, I was wondering the same. I remembered all these security issues hitting the news, but even then I was really wondering how much my home computers would really be at risk. And all the 'fixes' did say there would be something of a performance hit, also made me think that these fixes should be options for people. State that they are security fixes for ... and let people decide if they think it's really necessary for a computer that is mostly used for playing games on Steam.
    The average home user is probably going to fall victim to social engineering or some other means of getting sensitive information or administrative privileges than be hit by one of these, considering how difficult it is to pull off. Plus the average home user doesn't have much in the way of data that's profitable to them.
    Reply
  • InvalidError
    hotaru.hino said:
    Plus the average home user doesn't have much in the way of data that's profitable to them.
    And since most of those exploits rely on statistical analysis of CPU performance and known characteristics of the victim code to infer data, collisions between the exploit code and target code+data have to be frequent enough to build statistics to filter noise out. Not going to happen on a home PC that handles maybe a couple of site logins per day.
    Reply
  • mac_angel
    hotaru.hino said:
    The average home user is probably going to fall victim to social engineering or some other means of getting sensitive information or administrative privileges than be hit by one of these, considering how difficult it is to pull off. Plus the average home user doesn't have much in the way of data that's profitable to them.
    exactly. I'm pretty tech savvy and careful online. I try to teach my son the same. In the past he's had his Steam account stolen twice (I was able to get it back both times). I taught him to use LastPass and have LastPass generate the passwords for him. But none of that will matter when it comes down to the user. Even myself, I had my credit card info nabbed from one site just a couple of weeks ago. Two sites did two test transactions for something like $1.29 each. When they went through, a bunch of other sites started billing my credit card for odd amounts between $50 and $60. Luckily I caught it. But to stop it I had to cancel my credit card and open up an investigation that can take 2 weeks. I'm not sure what it is they do for investigating, but I think to the majority of people, looking at the sites they were affiliated with, and the progression of what and how it happened, it was pretty sketchy and obvious.
    Anyway, point is, I agree. I don't think those vulnerabilities really affect the majority of end users. But the performance hits that the fixes entail would. And we should be given an option to secure our computer, or keep our performance.
    Reply