Apple M1 chip contains hardware vulnerability that bypasses memory defense

Apple’s M1 chip has been found to contain a hardware vulnerability that can be abused to disable one of its defense mechanisms against memory corruption exploits, giving such attacks a greater chance of success.

MIT CSAIL computer scientists on Friday said they have identified a way to bypass the M1 chip’s pointer authentication, a security mechanism that tries to prevent an attacker from modifying memory references without being detected.

In a paper titled “PACMAN: Attacking Arm Pointer Authentication with Speculative Execution,” Joseph Ravichandran, ​​Weon Taek Na, Jay Lang, and Mengjia Yan describe how they were able to use speculative execution – the way in which modern processors perform calculations before they may or may not be needed to accelerate execution – to discern the pointer authentication Code that allows pointer modification on a protected system.

A pointer is a variable that stores the memory address of another variable, and those able to manipulate pointers can potentially access sensitive data in memory and run arbitrary code.

Pointer authentication was implemented in 2017 in Armv8.3 [PDF] to protect pointer integrity and was adopted by Apple in its Arm-based chip designs in 2018. It is present in Apple’s M1, M1 Pro, and M1 Max silicon, and has been adopted by other makers of Arm-based chips like Qualcomm and Samsung.

Pointer authentication relies on a cryptographic hash called a Pointer Authentication Code (PAC) – derived from the pointer value, a 64-bit context value, and a 128-bit secret key – to protect pointers from being modified. Because the used address space in 64-bit architecture is less than 64 bits – it’s 48 bits in macOS 12.2.1 on an M1 – the extra space can be used to store the PAC value, which can range from 11 to 31 bits.

When pointer authentication is active, an attacker must know the PAC value of the pointer after modification or the program will crash. A brute-force attack to find the PAC won’t work because a bad guess will cause a crash, resetting the hash value and forcing the attacker to start again.

Ravichandran and his colleagues have devised a PAC oracle – a feedback mechanism – that can be used to distinguish between correct and incorrect guesses without causing a program crash. This allows them to brute-force the possible values in about 2.94 minutes for a 16-bit PAC and to construct a control-flow hijacking attack on an application or operating system implementing pointer authentication.

“The key insight of our PACMAN attack is to use speculative execution to stealthily leak PAC verification results via micro-architectural side channels,” the researchers state in their paper.

The attack involves monitoring the interactions between translation lookaside buffers (TLBs) and caches to measure conflicts, the researchers explain.

It relies on software “gadgets” – pre-existing in-memory instruction sequences that can be chained together to perform desired functions. These are used to create a pointer verification function and a transmission function that speculatively sends the PAC verification result using a micro-architectural side channel.

The attack supposedly works across privilege levels – the described scenario involves unprivileged userspace obtaining information from the operating system kernel. It relies on having access to a high-resolution timer that can be used to measure the latency between micro-architectural events.

“To execute the PACMAN attack you need an existing software vulnerability,” said Ravichandran, a graduate student at MIT CSAIL, in an email to The Register. “PACMAN bypasses pointer authentication which is the last barrier to gaining arbitrary code execution.”

“Arbitrary kernel code execution essentially gives you unrestricted access to the device, and the attacker can do whatever they want (in essence they have gained ‘root’ access). Before you can do that, you need a software vulnerability so that you can execute the PACMAN attack using a PACMAN gadget (a snippet of victim code that can be used for performing the PACMAN attack).”

Last year, Hector Martin, founder and project lead of Asahi Linux, reported an M1 flaw called M1RACLES that wasn’t particularly consequential. At the time, he also alluded to a second CVE affecting the M1 that was not disclosed.

Ravichandran said he and his colleagues had only found this one flaw affecting the M1.

“We investigated the M1 chip as it is the first desktop CPU that shipped with pointer authentication,” he said. “We disclosed all our findings to Apple last year but we do not know if they have mitigated anything or not.”

The paper discusses potential mitigations of PACMAN, like pausing speculative execution with memory access and branch instructions, but notes that doing so may affect performance.

Ravichandran said he could not say whether Apple’s new M2 chip might be vulnerable because the researchers have not had a chance to investigate it.

“We believe that it is possible future Arm CPUs with pointer authentication and speculative execution may also be vulnerable to the PACMAN attack.”

The Register asked Apple whether it has addressed PACMAN in its M1 or M2, but we’ve not heard back.

The PACMAN paper is scheduled to be presented at the International Symposium on Computer Architecture in New York City on June 18. ®