Apple’s M1 chip has been found to contain a hardware vulnerability that can be exploited to disable one of its defense mechanisms against memory corruption exploits, giving such attacks a greater chance of success.
Computer scientists at MIT CSAIL said Friday they have identified a way to bypass the M1 chip’s pointer authentication, a security mechanism that attempts to prevent an attacker from changing memory references without being detected.
In an article 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 modern processors performed computations before they may or may not be needed to speed up execution – to discern 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 capable of manipulating pointers can potentially access sensitive data in memory and execute 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 manufacturers of Arm-based chips like Qualcomm and Samsung.
Pointer authentication relies on a cryptographic hash called the Pointer Authentication Code (PAC) – derived from the pointer value, a 64-bit context value, and a 128-bit secret key – to protect pointers against any modification. Since the address space used in the 64-bit architecture is less than 64-bit – it’s 48-bit 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 will not work because a wrong guess will cause a crash, resetting the hash value and forcing the attacker to start over.
Ravichandran and his colleagues have developed an oracle PAC – a feedback mechanism – that can be used to distinguish between correct and incorrect guesses without causing the program to crash. This allows them to brute force possible values in about 2.94 minutes for a 16-bit PAC and construct a control flow hijacking attack on an application or operating system implementing pointer authentication.
“The key idea of our PACMAN attack is to use speculative execution to stealthily leak PAC verification results through micro-architectural side channels,” the researchers state in their paper.
The attack consists of monitoring interactions between translation lookup buffers (TLBs) and caches to measure contention, the researchers explain.
It relies on software “widgets” – pre-existing sequences of instructions in memory that can be chained together to perform desired functions. These are used to create a pointer verification function and a transmit function that speculatively sends the PAC verification result using a micro-architectural side channel.
The attack is supposed to work across privilege levels – the described scenario involves unprivileged user space obtaining information from the operating system kernel. It relies on 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,” Ravichandran, a graduate student at MIT CSAIL, said in an email to The register. “PACMAN bypasses pointer authentication which is the last obstacle to executing arbitrary code.”
“Arbitrarily executing kernel code essentially gives you unrestricted access to the device, and the attacker can do whatever they want (in essence, they’ve gained ‘root’ access). Before they can do that , you need a software vulnerability to be able to perform the PACMAN attack using a PACMAN gadget (a snippet of code from the victim that can be used to perform the PACMAN attack).”
Last year, Hector Martin, founder and project manager of Asahi Linux, reported an M1 flaw called M1RACLES it was not particularly important. At the time, he also hinted at a second CVE affecting the M1 which has not been disclosed.
Ravichandran said he and his colleagues only found this one flaw affecting the M1.
“We studied the M1 chip because it’s the first desktop processor to ship with pointer authentication,” he said. “We disclosed all of our findings to Apple last year, but we don’t know if they mitigated anything or not.”
The article discusses potential PACMAN mitigations, such as suspending speculative execution with memory access and branch instructions, but notes that this may affect performance.
Ravichandran said he couldn’t say whether Apple’s new M2 chip might be vulnerable because researchers haven’t had a chance to study it.
“We believe it is possible that future Arm processors with pointer authentication and speculative execution may also be vulnerable to the PACMAN attack.”
The register asked Apple if they addressed PACMAN in their M1 or M2, but we got no response.
The PACMAN paper is scheduled to be presented at the International Symposium on Computer Architecture in New York on June 18. ®
#Vulnerability #discovered #Apple #chip