DEV Community

Cover image for GoFetch: A Security Flaw in the Apple's "M" Series
Samik Saraswat
Samik Saraswat

Posted on

GoFetch: A Security Flaw in the Apple's "M" Series

This post is dedicated to something serious that caught my attention a while back. Apple's "M" series MacBooks (M1, M2 and M3 series) have been found to contain a serious vulnerability. Now what makes this vulnerability a serious threat is its very nature, as it’s a bug in the silicon architecture design of the M series chip, which makes it unpatchable in nature. This is a problem that exists on the hardware level and cannot be fixed. Being a hardware level exploit, a physical device access is needed to exploit this vulnerability.

What exactly is this vulnerability:

This unfixable bug is called GoFetch. It’s type of a Side Channel Cache based memory attack, which in simpler words is a vulnerability in the Processing Unit that allows an unprivileged process to read data of another process as well as leak the cryptographic key(s) information. Take an example of a Process A [Malicious in nature] which can read the RSA or the AAS keys from another Process B [targeted victim involved in cryptographic authentication]. The novelty of the exploit lies in something known as a Side Channel Attack.

What is a Side Channel Attack:

To understand this attack, let’s consider that there’s a Password Checking Algorithm (PCA), which checks the input password with the known password. It iterates and checks every character and compares for matches with the known password. In this entire process, the processing time for correct character match (if the character from the input password is part of the known password) is less than the incorrect character match (if the character from input password is not part of the known password). The vulnerability lies in the deduction as the attacker will be able to deduce the correct password based on the time taken and the latency even if the input password is wrong. Here the operation itself is correct (in the sense, valid) but the implementation of such operations leaks out sensitive information from various channels (side channels: could be time, heat, sound etc) which aid in the reconnaissance of victim’s sensitive information. Therefore, the ability to deduce information through the latency of operation is known as a Side Channel Attack.

In-detail working of this attack:

As we know, Cache is shared by every process and it’s the fastest memory. Inside cache we have cache hits (when the cache has the data we want) and cache misses (when it doesn’t have the data), the access time for cache hits and misses actually reveals lot of information about the other processes that are using the cache memory in the form of access patterns (the access time variations for hits and misses) using the same memory. To mitigate this sort of vulnerability, a way around it exists, known as constant time programming. The objective of constant time programming is to design the architecture such that the cache hits or misses takes same time every time. But the safety comes with a tradeoff- a disadvantage in the optimisation and the speed of operations resulting in extremely slow CPU (safe and secure but extremely slow) that is not optimised for certain processes (as every process will take same time then). Most of the processes are run in the constant time programming but some specific processes do not adhere to it (to not sacrifice the user experience by being very slow), and this is the part where Apple Silicon bug comes into play, which makes use of something called as Data Memory dependent Prefetchers (DMPs). DMPs are used to read all the memory in cache which someone (another process) is accessing. The prefetchs looks in the memory and checks if there are any pointers that maybe needed in future, and if those pointers exist, it goes in the memory and fetches, other memory. The main vulnerability lies in the failure to validate if it’s a pointer or not (anything that looks like a pointer will be loaded and fetched by the DMPs as well). The access of pointers and pointer lookalikes do not adhere to constant time programming, with the intent to optimise the performance of Processing Unit. Therefore, a process is able to listen in, on another process, revealing the memory within (including sensitive information such as cryptographic keys) which makes use of a timing based Side Channel Attack using cache.

So far Apple has not publicly addressed this major security flaw embedded into the architecture itself. Preventive measures against this includes taking care of your device because physical device access is needed to exploit this vulnerability. It seems Apple’s obsession with optimisation and speed led to a major security flaw :) and being an Apple MacBook (M1) user myself, I felt the need to raise awareness about this issue. Since lot of workplace organisations give Apple MacBooks to interns and full time employees, this is something that they should not overlook. Although this doesn’t pose any threat to Apple Device owners until a malicious physical access to the device is established so no need to worry :)

GoFetch Paper: https://gofetch.fail/files/gofetch.pdf

Top comments (0)