M4 and GoFetch

[superdupernerd]

I’m thinking of making 2025 my upgrade year. I have a late-model Intel Mac.

TBH, the GoFetch thing is a problem because I handle union members’ personal information for legal work. From what I understand, GoFetch is a local vulnerability, but that doesn’t give me comfort if I’m going to be carrying around a device that can be easily stolen or lost.

I know we won’t know for sure until the M4 is released and those researchers test it. But in general, just related to product development times… GoFetch was discovered a little over a year ago. Is that enough time for Apply to patch it on the M4s or do you think this is going to be resolved in the M5 generation? From what I understand, Apple Silicon development takes a couple years prior to release.

Even though my union work doesn’t require horsepower, I do CAD and graphic design on the side, so I would like to get into the Apple Silicon tier of computing power.

 

[mr_roboto]

I know we won’t know for sure until the M4 is released and those researchers test it. But in general, just related to product development times… GoFetch was discovered a little over a year ago. Is that enough time for Apply to patch it on the M4s or do you think this is going to be resolved in the M5 generation? From what I understand, Apple Silicon development takes a couple years prior to release.

You're worrying about GoFetch far more than it deserves.

One issue with the way security research works is that the main way for researchers to attract funding is by making a big splash. Often this means hyping up a minor and ultimately inconsequential discovery. This is why GoFetch has a cute artist-designed logo, a cute name, a website with a custom domain (gofetch.fail), and lots of press coverage. The problem is, many of the things you see press coverage of aren't actually practical for attackers to exploit, and early grandiose claims (such as "it's unpatchable!") may not stand up to scrutiny.

This one's difficult to exploit in the real world - it requires a minimum of ~1hr of an attacker process continuously hammering on a victim process, both written by the researchers. If the crypto algorithm chosen in the victim isn't optimal for the attack, it can take ~10hr instead. They never demonstrated an attack against any of Apple's system-provided cryptography, and this is probably because they can't - even mild hardening against brute-force attacks (think simple rate-limiting) defeats GoFetch.

To cap it all off, shortly after the initial big press splash, Hector Martin (a principal developer in the Asahi Linux project) quickly discovered that at least as early as M2, Apple was already providing a mode control bit to disable the CPU performance feature that GoFetch exploits. (This control bit may be present in M1 too, he didn't try it there.) So you can cross GoFetch out as a concern; it's 100% software patchable from M2 onwards, and possibly M1 too.

Hector's post about it:

Hector Martin (@marcan@treehouse.systems)

Found the DMP disable chicken bit. it's `HID11_EL1<30>` (at least on M2). So yeah, as I predicted, GoFetch is entirely patchable. I'll write up a patch for Linux to hook it up as a CPU security bug workaround. (`HID4_EL1<4>` also works, but we have a name for that and it looks like a big...

social.treehouse.systems

 

[leman]

Hi @superdupernerd, as @mr_roboto eloquently explains above, there is not much reason to worry about GoFetch. The attack has only so far been demonstrated on carefully crafted examples, and even under those ideal circumstances this attack is wildly impractical. There is no obvious way to use this attack vector to extract user passwords or system certificates on a stolen machine.

Your worry in handling sensitive data on a local machine is understandable and reasonable. I would say that a Mac is a more secure laptop for these things thanks to the many security features that Apple has included, such as built-in location tracking, encrypted filesystem, and the ability to execute a remote device wipe. Unless you are being targeted by an organization with deep pockets and access to world-class hackers, I'd say you will be fine. And if the secret service is really after you, well, than it does not really matter which computer you use

 

[superdupernerd]

Hahaha nice.

This is all reassuring.

Question: If disabling the CPU performance feature is the software patch. Doesn’t it then stand to reason that this would affect my CAD, 3D modelling and occasional virtual machine PC gaming performance if Apple releases a patch? I wouldn’t want to suddenly noticeably lose performance over a security patch pushed out by Apple.

 

[mr_roboto]

Hahaha nice.

This is all reassuring.

Question: If disabling the CPU performance feature is the software patch. Doesn’t it then stand to reason that this would affect my CAD, 3D modelling and occasional virtual machine PC gaming performance if Apple releases a patch? I wouldn’t want to suddenly noticeably lose performance over a security patch pushed out by Apple.

I can't say for sure, but you probably wouldn't lose performance in most applications. It doesn't have to be disabled globally, only during execution of sensitive code like cryptography.

 

[superdupernerd]

If the storage is encrypted, doesn’t that mean the computer is always running cryptography code though?

I guess I’m confused what sorts of scenarios would be impacted by such a patch.

 

[leman]

Hahaha nice.

This is all reassuring.

Question: If disabling the CPU performance feature is the software patch. Doesn’t it then stand to reason that this would affect my CAD, 3D modelling and occasional virtual machine PC gaming performance if Apple releases a patch? I wouldn’t want to suddenly noticeably lose performance over a security patch pushed out by Apple.

ARM provides a special instruction that tells the system you want to do secure computation. This instruction is supposed to disable features that could lead to data leakage. One issue with GoFetch is that Apple’s implementation of this instruction does not disable certain speculation. Overall, them fixing this “secure compute mode” will have zero impact on performance because you are not using the mode to do high-performance computation in the first place.

If the storage is encrypted, doesn’t that mean the computer is always running cryptography code though?

That is done by dedicated hardware in the storage controller/Secure Enclave. GoFetch only affects code running on the CPU. Quite a lot of cryptography on macOS system is offloaded to the security processor, which is one of the reasons GoFetch has little practical relevance.

 

[mr_roboto]

@leman beat me to it - I totally forgot to mention that all cryptography done in the Secure Enclave is off-limits to a GoFetch-style attack.

 

[superdupernerd]

Is this the same thing? Homeboy uses a few common terms describing this and GoFetch. Also, I dunno if “all ARM” applies to Apple, as I could see Apple making their own proprietary version.

As long as the storage and passwords are safe, and any patching won’t hurt performance, I couldn’t be arsed about it. Though in the GoFetch example, he uses a password hash process for his example.

Because if GoFetch and the bug described in this this video don’t endanger things in the above paragraph, I might just save money and buy a used Pro. To call my current Pro long in the tooth, is to redefine long. Hahahaha.

 

[mr_roboto]

I didn't watch the video thanks to the clickbaity title image, I just skimmed through the paper describing TikTag. It's an attack against Arm's Memory Tagging Extension (MTE), an optional security enhancement added to the ARM ISA in ARMv8.5-A. MTE is intended to guard against memory corruption attacks.

The paper's intro doesn't talk about the source of corruption, probably because that's out of scope for it. I suspect MTE's specifically about mitigating Rowhammer, a class of attack wherein a process rapidly accesses or "hammers" on a particular row of DRAM. By using specific data patterns and hammering quite intensely, it's possible to corrupt adjacent rows in the DRAM array.

This is a vulnerability inherent to DRAM itself - it exists across all instruction set architectures. CPU designers have begun to experiment with mitigations, and MTE appears to be an attempt at that.

Unfortunately, what the paper lays out is that problems with the design of MTE allow an attacker to specifically target and bypass MTE's protections. While this is bad, I think it only leaves you back where you were before the existence of MTE.

MTE appears to mostly be an Android/ChromeOS thing. Apple doesn't seem to have implemented it in their CPUs, and therefore not in their operating systems either.

For what it's worth, my level of concern about Rowhammer attacks is pretty low. They're difficult to reliably exploit, because the corruption is semirandom - an attacker doesn't have total control over what it hits, or how it hits it. If I were responsible for security in a cloud services provider, I'd be far more worried about it, but not on my personal devices.

 

[flaubert]

Also, exploits like rowhammer are only possible once the attacker has code running on your machine. As such, it is not really a scenario to worry about for a personal, single-user machine (if an attacker is running code on your machine then it is already compromised, and the attacker is more likely to watch keystrokes, read the clipboard, etc). Rowhammer is more of an issue for cloud service providers, a situation where multiple customers are running untrusted code on the same processor, and customer A can run code using rowhammer to try and break security on customer B.

 

[MacYak]

... only possible once the attacker has code running on your machine ...

Hm, after all, every website executes code on your machine. That's just JavaScript. I also wonder if the problem with the data memory-depending prefetchers that GoFetch exploits is fixed with the M4 chips.

 

[mr_roboto]

Hm, after all, every website executes code on your machine. That's just JavaScript. I also wonder if the problem with the data memory-depending prefetchers that GoFetch exploits is fixed with the M4 chips.

DMP prefetch is inherently vulnerable to something like GoFetch, you can't really "fix" it.

Because advanced prefetch is too important to performance to give up, the way Arm chose to deal with it and other issues was to introduce an optional FEAT_DIT extension. Whenever a program wants to harden its cryptography subroutines against all attacks in the GoFetch family, it can use FEAT_DIT instructions to temporarily enable a CPU mode which reduces performance, but guarantees constant-time instruction execution regardless of data patterns. (DIT = Data Independent Timing.)

Even M1 supports FEAT_DIT. The vulnerability is that in M1 and M2, using FEAT_DIT does not turn off the DMP prefetcher. However, as of M3, FEAT_DIT turns off DMP, so there is no need to wonder about M4.

Nobody should be worried about GoFetch. It was never a demonstration of a practical attack against Macs, because macOS does critical cryptography in the Secure Enclave, not on the CPUs. Furthermore, even if you're doing cryptography on the CPUs, it can be blocked by any of FEAT_DIT on M3 onwards, the DMP disable bit on M2 (probably present in M1 too), or even just simple attack detection heuristics in the process that's serving cryptography requests.

(The heuristic and response: is one client submitting hundreds of thousands of failed decryption requests per second? Then rate-limit the probable attacker to just one request per second, and it'll take them 100+ years to extract a key, which for all practical purposes is the same as "never".)

 

[MacYak]

Thanks for the detailed explanation @mr_roboto