Apple Silicon vulnerability leaks encryption keys, and can't be patched easily
A new vulnerability in Apple Silicon chips can allow a determined attacker to access a user's data by stealing the cryptographic keys -- and a fix could considerably impact encryption performance.
Apple Silicon M2 in front of a MacBook
Researchers have discovered an issue with Apple's M-series chips, in how it deals with cryptographic operations, such as the encryption of files. However, since it is an issue with the chip's architectural design, it's something that's very difficult to mitigate.
Detailed on Thursday by a group of researchers and reported by ArsTechnica, the problem lies in the data memory-dependent prefetcher (DMP), which predicts memory addresses of data that will most likely be accessed by currently-running code. By prefetching data, it becomes a target for probing from malicious code.
This is because prefetchers are using previous access patterns to determine its predictions of the next bit of data to fetch. It is possible for an attacker to use this way of working to influence the data being prefetched, opening the door to accessing sensitive data.
GoFetch attack can steal encryption keys
The attack, referred to by the researchers by the name "GoFetch," takes advantage of a quirk in DMP usage in Apple Silicon. Specifically how a DMP could confuse the content of memory with pointer values used to load more data, with the former occasionally used as the latter.
In explaining the attack, the researchers confirm that it is possible to make the data "look like" a pointer, which the DMP will treat as an address location and in turn pull that data to the cache. The appearance of the address in the cache is visible, meaning malicious code can see it.
The attack manipulates data within the encryption algorithm to look like a pointer, using a chosen input attack. The DMP, seeing the data value as appearing like an address, then brings the data from that address, with the address itself being leaked.
The attack is not an instant crack of an encryption key. However, the attack can be carried out repeatedly, allowing the key to be revealed over time.
The GoFetch attack uses the same user privileges as many other third-party macOS apps, rather than root access. This lowers the barrier to entry for actually run the attack, but it's not entirely the whole story.
The GoFetch app running the attack must also be used on the same chip cluster as the cryptographic target app in order to function, and both must use the efficiency cores or the performance cores at the same time. It is cluster-dependent, meaning that it will still work if the apps are run on different cores within the same cluster.
The researchers claim the attack works against classic encryption algorithms as well as newer quantum-hardened versions.
As to its effectiveness, the researchers' test app was able to extract a 2,048-bit RSA key in less than an hour, and just over two hours for a 2,048-bit Diffie-Hellman key. Ten hours of data extraction is needed to secure a Dilithium-2 key, excluding offline processing time.
Difficult to thwart
The main problem with the attack is that it's one that cannot be patched in Apple Silicon itself, since its a central part of the design. Instead, it requires mitigations by the developers of cryptographic software to work around the problem.
The problem is that any mitigation changes will increase the workload required to perform the operations, in turn impacting performance. However, these impacts should only affect applications that use encryption and employ the mitigations, rather than other general app types.
In the case of one mitigation, ciphertext blinding, the effectiveness varies between algorithms, and can require twice the resources than usual.
Running the processes only on efficiency cores is also a possibility, since they do not have DMP functionality. Again, encryption performance will take a hit since it's not running on the faster cores.
A third option actually applies to M3 chips, in that a special bit can be flipped to disable DMP. The researchers admit they don't know the level of performance penalty that would occur.
Apple declined to comment to the report on the matter. The researchers claimed they performed a responsible disclosure to Apple before the public release, informing the company on December 5, 2023.
Some of the researchers previously worked on another discovery from 2022, also concerning Apple Silicon's DMP usage. At the time, the so-called Augury flaw was deemed to be not "that bad," and was "likely only a sandbox threat model."
History repeating
Chip vulnerabilities can be a big problem for device producers, especially if they have to make changes to operating systems and software in order to maintain security.
In 2018, Meltdown and Spectre chip flaws were discovered, which affected all Mac and iOS devices, as well as nearly every X86 device produced since 1997.
Those security exploits relied on "speculative executive," when a chip would improve its speed by working on multiple instructions simultaneously, or even out of order. As the name suggests, the CPU will speculatively continue executions down a path before a branch completes.
Both Meltdown and Spectre used the functionality to access "privileged memory," which could include the CPU kernel.
The discovery of the flaws led to a flood of other similar attacks, chiefly against Intel chips, including Foreshadow and Zombieload.
This is also not the first issue found with the design of Apple Silicon chips. In 2022, MIT researchers discovered an unfixable vulnerability dubbed "PACMAN," which capitalized on pointer authentication processes to create a side-channel attack.
Read on AppleInsider
Comments
As most attacks, this requires you - at the very least - to download and run an app of unknown origin. Don't do that.
Well, it's not always that simple. A couple of times a year there's a security issue that allows arbitrary code execution when processing an image or some other type of data - sometimes already in the wild. If your un-patched phone visits a website with such malicious content, or sometimes even receive a text containing it, you've "downloaded an app of unknown origin" and run it without even knowing it.
Sure it can - to a point. The app store definitely scans app code for malicious activity such as this. It's a cat-and-mouse game, though, as malware tries to obfuscate what it's doing. So it's not perfect, but it's far from useless.
If patching attacks on Intel server chips back around a decade ago, performance would drop 25-50%.
Build a better mouse-trap, and the miscreants will build a better mouse.
Malicious code has been hidden in spreadsheet macros, various graphics and video images (including advertisements) and just about anything else you can imagine. Among the more dangerous is use of social engineering to convince you that a boss wants certain work done, causing you to open a document that then infects the corporate servers and encrypts the data, followed by a bitcoin ransom request, possible sale or disclosure of the data, and a report to the government if you do not report the ransom attack by the government imposed deadline (4 days, if I remember correctly). A large number of pharmacies and mostly small medical groups are suffering financially from such an attack on a company that processes payments for those insured by Tricare (including retired military), Medicare, and a host of insurance companies.
this is a bummer of an issue, but not the end of the world and nowhere near what Intel and AMD got hit with years ago.
So again we have another performance enhancing functionality that was implemented with very good intentions that fell victim to a specific exploit. In retrospect, and with the knowledge of similar exploits in optimization logic that we saw with Spectre, maybe it could have been scrutinized a little more thoroughly during design and verification? I only say that because the Spectre vulnerabilities were put into code 10-20 years prior to their discovery, when security wasn't at the forefront of all concerns as it is today. It was all about performance and efficiency. Anything that is totally new, unique, and hasn't been done before by the development team should probably trigger a heightened level of concern with security being baked-in and scrutinized at every level from the start.
Apple obviously has great designers, engineers, and scientists who truly know what they are doing. They have an extremely difficult job of trying to bring as much value to Apple's customers as possible. Unfortunately, there are just as many hackers, some of them bad guys, who are just as smart and clever as Apple's best people out there trying to break Apple's best stuff. Fortunately there are a lot of good guy hackers out there who get a very high level of satisfaction from finding vulnerabilities in other peoples code and reporting what they find in a very fair and equitable way. Nobody like having someone else pointing out their flaws, but the ethical hackers are providing an incredibly valuable and vital service and are probably underappreciated for all they do.
Finally, the architecture upon which most digital computers since the earliest days to today are based on were never designed with security, fault tolerance, efficiency, performance, or usability (just to name a few qualities) in mind. At some point we'll have to rebase the most basic notions of how computers work to account for all of the things that the current architectures, even as evolved as they are today, overlooked at the point of their inception.
It sounds like your exiting machine has a bug causing frequent crashes. It could be something corrupted in the OS, so you may want to try reinstalling the operating system or taking it to the Apple Genius Bar for them to look at. It could be a hardware bug, but usually such things are a bit of data in flash gone bad, or something along those lines.
Do you understand speculative processing bugs?.