Apple chip designers tried to make CPUs more speedy, but in fact made them less secure. A team of academics found a way to exploit a bug in the M1, M2 and M3 processors that let them steal secrets—such as encryption keys. They’re calling it GoFetch.

It’s yet another prediction faux pas. In today’s SB Blogwatch, we cache in on the story. [You’re fired—Ed.]

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Le joli Coco.

“Requires less than an hour”
A newly discovered vulnerability baked into Apple’s M-series of chips allows attackers to extract secret keys from Macs when they perform widely used cryptographic operations. … It stems from the microarchitectural design of the silicon itself, [so] can only be mitigated [in] software, which could drastically degrade … performance.
…
The threat resides in the chips’ data memory-dependent prefetcher [DMP], a hardware optimization that predicts the memory addresses of data that running code is likely to access in the near future. … The GoFetch app requires less than an hour to extract a 2048-bit RSA key, … two hours to extract a 2048-bit Diffie-Hellman key, … 54 minutes to extract … a Kyber-512 key and about 10 hours for a Dilithium-2 key. … It’s probably also wise to assume, at least for now, that other cryptographic protocols are likely also susceptible.

“Drastic fix”
Apple’s DMP implementation sometimes confuses actual memory content with the pointer used to predict the memory address. … An attacker can exploit this confusion to correctly guess bits of a cryptographic key until the whole key is uncovered.
…
The most “drastic” fix would be to disable the DMP, while another possibility is to run cryptographic code on the chip’s efficiency cores because these cores do not have DMP. … Long-term, the researchers recommend that Apple find ways for macOS to better manage the DMP usage and “selectively disable” [it].

“Cache-timing analysis”
We reverse-engineered DMPs on Apple M-series CPUs and found that the DMP activates (and attempts to dereference) data loaded from memory that “looks like” a pointer. This explicitly violates a requirement of the constant-time programming paradigm, which forbids mixing data and memory access patterns.
…
We craft chosen inputs to cryptographic operations, in a way where pointer-like values only appear if we have correctly guessed some bits of the secret key. We verify these guesses by monitoring whether the DMP performs a dereference through cache-timing analysis. … We disclosed our findings to Apple on December 5, 2023.

This is the sort of thing that would metaphorically drive me to drink if I were implementing crypto code. It’s an uphill battle at the best of times, but even if I finally get it all right, there’s dozens of processor features both current and future ready to blow my code up at any time.
…
As long as we’re getting efficiency cores and such, maybe we need some “crypto cores” added to modern architectures, that make promises specifically related to constant time algorithms like this and promise not to prefetch, branch predict, etc. Sort of like the Itanium.

That sucks, but points to something I keep saying: … We’ve taken the complexity of computer systems and networks past the point where it’s possible to engineer any of it without it all containing serious flaws.
…
When I say this to many IT people, they just shrug it off or make snarky comments about the field just needing to get some better-trained/educated workers. But … nobody can wrap their heads around any of this stuff anymore.
…
In recent years, we’ve seen this move to bake security directly into hardware that’s not feasible to just swap out when bugs are found. Either that, or at least it requires vendor-specific firmware upgrades … with people running lots of vulnerable gear because someone stopped paying for the ability to upgrade it.

How tricky it is to prevent modern compiler+hardware platforms from optimizing based on your secret data, which almost invariably ends up leaking your secret data. … I have to disable hardware prefetchers because I already software prefetch everything that’s predictable and thus the hardware prefetchers are at best useless to me and can only make false-positive mistakes.
…
The idea of a prefetcher that hair-triggers off my data bits merely being a valid address gives me hives. It feels like a violation. The kind of brilliant abstraction violation that makes ****py, lazy, serialized-latency-limited code faster, but where the loss of control ends with me in a padded room muttering about my inability to explain non-deterministic benchmark results.

The hidden print flaw and 2 other zero days which a text message was sent, you never got it/received any notification … and it exploited the 3 zero days in the background installing malicious software just waiting to be used later on. App store scanning doesn’t mean much when it is typically zero day exploits that are a means to get your Mac/iPhone to perform some function to then exploit this vulnerability.
…
Is the M3 now turned into an M1? [It] doesn’t sound … good for performance.

Large caches where the same data exists in both cache and RAM are inherently vulnerable to side channel attacks. There will be more. … I hope Apple finds a fix that doesn’t hurt performance too much.

Free hardware updates to M4 for everyone!

In other words: “NSA backdoor found in Apple silicon.”

Recent Articles By Author