New chip flaw hits Apple Silicon and steals cryptographic keys from system cache — 'GoFetch' vulnerability attacks Apple M1, M2, M3 processors, can't be fixed in hardware

Apple Silicon is sad
(Image credit: Apple)

Researchers have discovered a massive security vulnerability inside Apple M1, M2, and M3 silicon. The vulnerability, dubbed 'GoFetch,' steals cryptographic information from the CPU cache enabling an attacking program to build a cryptographic key from stolen data, allowing the application to access sensitive encrypted data. Ars Technica first reported on the security flaw. 

GoFetch takes advantage of an overlooked security exploit in Apple silicon surrounding its state-of-the-art data memory-dependent prefetcher (DMP). A next-generation prefetcher only found in Apple silicon and Intel's Raptor Lake CPU architectures that loads memory contents into cache before they are needed. The vulnerability surrounds an overlooked behavior in the prefetcher where it will load key material into the CPU cache featuring a pointer value that is used to load other data. DMP will sometimes confuse memory content and load inappropriate data into the CPU cache.

The problem with this vulnerability is that it completely neutralizes the security effects of constant-time programming, which is a side-channel mitigation encryption algorithm used to defeat prefetcher-related side-channel/CPU cache-related attacks. As a result, applications utilizing GoFetch can trick encryption software into putting sensitive data into the cache for the attacking application to steal.

This is a serious vulnerability that affects all kinds of encryption algorithms, including 2,048-bit keys that are hardened to fend off attacks from quantum computers. Unfortunately, there is no way to patch the vulnerability in silicon. The only way forward is software-based mitigations that will slow down M1, M2, and M3's encryption and decryption performance. Technically, developers can force their encryption software to run only on the E-cores, which do not have this prefetcher, however, this comes at an obvious performance cost too.

The only exception is Apple's M3 silicon which purportedly features a special "switch" that developers can turn on to disable the chip's data memory-dependent prefetcher. However, nobody knows yet how much performance will be lost if this special optimization is turned off. For all we know, it could hinder performance just as much as software mitigation.

The interesting tidbit is that Intel's Raptor Lake CPU architecture (which includes both 13th and 14th Gen CPUs) doesn't have this vulnerability despite sharing the same prefetcher as Apple's M series chips. We don't know why this is the case, but it demonstrates that this vulnerability can be patched in silicon. However, this will only occur in future Apple M series architectures (i.e. M4) when Apple's engineers have time to re-design its CPU architecture to account for the recently discovered vulnerabilities.

Apple has yet to publish any release dates for an official fix, but due to the vulnerability this issue poses, we suspect a fix will arrive within the year.

The researchers that published the information hail from the University of Illinois Urbana-Champagne; University of Texas at Austin; Georgia Insitute of Technology; University of California, Berkeley; University of Washington; and Carnegie Mellon University.

Aaron Klotz
Contributing Writer

Aaron Klotz is a contributing writer for Tom’s Hardware, covering news related to computer hardware such as CPUs, and graphics cards.

  • I wouldn't call this an entirely new threat on Apple DMPs though.

    Remember AUGURY ? However, there was this "false notion" that this augury didn't pose much of a threat, that it could only leak data pointers and likely only in the 'sandbox threat' model, (and a fault that Augury was unable to mix data and addresses when constant-time practices were used).

    Some researchers thought it only prefetched when the content was a valid virtual address.

    https://www.prefetchers.info/

    "The only exception is Apple's M3 silicon which purportedly features a special "switch" that developers can turn on to disable the chip's data memory-dependent prefetcher."

    What switch ? They are talking about a special bit which can be flipped to disable DMP. DIT bit set on M3 effectively disables the DMP. This is not the case for the m1 and m2.

    Some suggest using a lib like 'libsodium' to simply set the disable bit prior to cryptographic operations that are sensitive on M3, but this sounds impractical.

    https://developer.arm.com/documentation/ddi0601/2023-12/AArch64-Registers/DIT--Data-Independent-Timing
    "The interesting tidbit is that Intel's Raptor Lake CPU architecture (which includes both 13th and 14th Gen CPUs) doesn't have this vulnerability despite sharing the same prefetcher as Apple's M series chips. We don't know why this is the case,"
    Because the DMP found in Intel’s Raptor Lake processors doesn’t leak the same sorts of cryptographic secrets.

    Apart from that, this DOIT bit can also effectively turn off the DMP. Raptor Lake processors can disable DMP by using the Data Operand Independent Timing bit.

    https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/data-operand-independent-timing-isa-guidance.html
    Reply
  • rluker5
    Large caches where the same data exists in both cache and ram are inherently vulnerable to side channel attacks. There will be more.

    A shame since speeding up access to data is so helpful in speeding up the total time to process. I hope Apple finds a fix that doesn't hurt performance too much.
    Reply
  • Amdlova
    No way this can be true... apple made perfect products. Perfect silicon...
    This can't be right...
    This notice made from intelfanboism
    Reply
  • bit_user
    Amdlova said:
    No way this can be true... apple made perfect products. Perfect silicon...
    This can't be right...
    As you burn that strawman, make sure nothing else catches alight.
    Reply
  • greenreaper
    bit_user said:
    As you burn that strawman, make sure nothing else catches alight.
    Apple's stock is already up in smoke.

    (OK, so it's not anywhere near that bad, but the heady days of 4x growth don't seem likely to come back anytime soon.)
    Reply
  • Ogotai
    Amdlova said:
    No way this can be true... apple made perfect products. Perfect silicon...
    This can't be right...
    you sound like someone on anadtechs forums...
    Reply
  • mitch074
    Ogotai said:
    you sound like someone on anadtechs forums...
    Except THEY don't have the implicit /sarcasm tag.
    Reply
  • bit_user
    greenreaper said:
    Apple's stock is already up in smoke.
    Yeah, and I'm sure it has nothing to do with these current events:
    Apple fined €1.8bn by EU for breaking streaming rules DOJ sues Apple over iPhone monopoly in landmark antitrust case
    Reply
  • TechyIT223
    Amdlova said:
    No way this can be true... apple made perfect products. Perfect silicon...
    This can't be right...
    This notice made from intelfanboism
    sarcasm much ? 😉
    Reply
  • TechyIT223
    bit_user said:
    Yeah, and I'm sure it has nothing to do with these current events:
    Apple fined €1.8bn by EU for breaking streaming rulesDOJ sues Apple over iPhone monopoly in landmark antitrust case
    Interesting links. Thanks for sharing
    Reply