Newly Discovered Variants Of Meltdown/Spectre Exploit Cache Coherency Across Cores

Researchers created a new method of exploiting the Meltdown and Spectre vulnerabilities, which they’ve dubbed MeltdownPrime and SpectrePrime, that works by observing the effects of speculative execution on data shared between caches of different CPU cores. Existing software mitigations for Meltdown/Spectre are believed to be effective against the new variants.

Princeton and Nvidia researchers teamed up to produce a testing method that can generate code that represents the essence of an attack. More precisely, their method is CPU architecture-aware, so it emulates exactly what a software attack would translate into on the hardware level. According the the researchers, their tool can be used to quickly generate a set of “security litmus tests” for a class of security exploits.

The following is taken from the researchers’ paper:

We have developed a tool for automatically synthesizing microarchitecture-aware assembly language programs given two inputs: (i) a formal description of a microarchitecture in a domain-specific language [...], and (ii) a formal description of a microarchitectural execution pattern of interest. This tool is consequently capable of synthesizing implementation-aware programs that can induce any user-specified threat pattern representative of a class of security exploits.

In the process of their testing, they discovered that the speculative execution methods that are exploited by the Meltdown and Spectre vulnerabilities leave a trail that might not be observable in only a CPU’s shared cache, but in its cores’ individual caches as well. The explanation lies in the design of the invalidation-based cache coherence protocol of many CPUs.

CPU caches are a small snapshot of parts of the system memory. Because memory access only occurs for things that are not already in the cache, it’s actually the cache that holds the most up-to-date version of the memory. A multi-core CPU has shared caches, as well as per-core caches. Cores working with the same memory will each have their own snapshot of that memory in their individual cache. When one core modifies its cache, it’s the equivalent of it modifying the memory, so the other cores’ caches become out of date. The cache coherency protocol is the process by which the other cores are notified that their cache is invalid.

The Meltdown/Spectre vulnerabilities break the principle of speculative execution being undetectable to software by modifying shared caches in a way that persists and is detectable across software process boundaries. What the researchers discovered is that, because certain caches might be partially mirrored across cores, the effects of speculative execution occurring on one core can be detectable on another core. Test cases exploiting this principle created by the researchers were able to recover hidden data at 99.95% accuracy. By comparison, their test cases of a traditional Spectre exploit only reached 97.9% accuracy.

Before you get too alarmed, the researchers said that current software-based Meltdown/Spectre mitigations seem successful in blocking their new exploits. However, these exploits will likely need their own distinct fix, different from those for traditional Spectre, if they are to be mitigated in hardware. It looks like Intel and AMD will have their work cut out for them in their next generation of CPUs.

  • InvalidError
    Now that security researchers are focusing on side-channel style attacks, I bet these are only the tip of the iceberg for architectural side-channel discoveries and we'll likely see more of those as the research field expands to more architectures and more aspects of each of them.
    Reply
  • meyers.bt
    This is nothing new. They've been studying side-channel attacks for ages. People have already forgotten this gem from 2005: http://www.daemonology.net/papers/htt.pdf
    Reply
  • bit_user
    20711642 said:
    This is nothing new. They've been studying side-channel attacks for ages. People have already forgotten this gem from 2005: http://www.daemonology.net/papers/htt.pdf
    Was it forgotten? I remember reading that Intel was initially skeptical of it, but I've since seen thread QoS and isolation features go into server CPUs I thought were intended to mitigate against it.
    Reply
  • meyers.bt
    BIT_USER, I said that in regard to the previous comment because they seemed to be under the impression that we were only just beginning to take side-channel attacks in CPU designs seriously. You are absolutely correct in that Colin's particular exploit has long since been remedied in hardware. I was merely using it as an example of how exploits like this are not really all that new, just far more sophisticated than their predecessors.
    Reply
  • InvalidError
    20711791 said:
    BIT_USER, I said that in regard to the previous comment because they seemed to be under the impression that we were only just beginning to take side-channel attacks in CPU designs seriously.
    I know side-channel attacks aren't new, some people have also made side-channel attacks by monitoring power draw and EMI from chips too. Nearly 15 years between significant architecturally exploitable side-channels however is a surprisingly long time between discoveries for bugs that have been there all along, hence my impression that research in that direction landed on the back-burner for much of that time.

    Now that the spotlight has been brought back onto them with Spectre, Meltdown and a new set of closely variants thereof mere months after the original disclosures, AMD, Intel and ARM have the whole security community scrutinizing their instruction set and architecture for new security holes to a likely unprecedented degree.
    Reply
  • apesoccer
    I like pie.
    Reply