Apple’s M1 chip has been found to contain a hardware vulnerability that could be abused to disable one of its memory corruption exploits, giving these attacks more chances of success.
MIT CSAIL computer scientists said Friday that they have identified a way to prevent the authentication of the M1 chip pointer, a security mechanism that attempts to prevent an attacker from modifying memory references without being detected.
In an article entitled “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 perform calculations before . they may or may not be needed to speed up execution: to discern the pointer authentication code that allows pointer modification in a secure system.
A pointer is a variable that stores the memory address of another variable, and those who are able to manipulate pointers can potentially access memory-sensitive data and execute arbitrary code.
Pointer authentication was implemented in 2017 in Armv8.3 [PDF] to protect the integrity of the pointer and was adopted by Apple in its Arm-based chip designs in 2018. It is present in Apple’s silicon M1, M1 Pro and M1 Max, and has been adopted by other chip-based manufacturers. Arm like Qualcomm and Samsung.
Pointer authentication is based on a cryptographic hash called Pointer Authentication Code (PAC), derived from the pointer value, a 64-bit context value, and a 128-bit secret key, to protect pointers from modification . Because the address space used in the 64-bit architecture is less than 64 bits (it is 48 bits in macOS 12.2.1 on an M1), the extra space can be used to store the PAC value, which can oscillate between 11 and 31 bits.
When pointer authentication is active, an attacker must know the PAC value of the pointer after the modification or the program will be blocked. A brute force attack to find the PAC will not work because a bad guess will cause an accident, resetting the hash value and forcing the attacker to start again.
Ravichandran and his colleagues have devised an oracle PAC, a feedback mechanism, which can be used to distinguish between right and wrong conjectures without causing a program error. This allows them to force possible values in about 2.94 minutes for a 16-bit PAC and build a control flow hijacking attack on an application or operating system that implements pointer authentication.
“The key idea of our PACMAN attack is to use speculative execution to stealthily filter the results of PAC verification using microarchitectural side channels,” the researchers say in their article.
The attack involves monitoring interactions between translation buffers (TLBs) and caches to measure conflicts, the researchers say.
It is based on software “gadgets”: sequences of pre-existing instructions in memory that can be chained together to perform the desired functions. They are used to create a pointer verification function and a transmission function that speculatively sends the result of the PAC verification through a microarchitectural side channel.
The attack supposedly works through privilege levels: the scenario described implies that the unprivileged user space obtains information from the operating system kernel. It is based on having access to a high-resolution timer that can be used to measure latency between microarchitectural events.
“To run the PACMAN attack you need an existing software vulnerability,” Ravichandran, a graduate student at MIT CSAIL, said in an email to The Register. “PACMAN ignores pointer authentication, which is the last barrier to getting arbitrary code execution.”
“Arbitrary execution of the kernel code essentially gives you unrestricted access to the device, and the attacker can do whatever it wants (in essence, it has gained” root “access). Before doing so, you need a software vulnerability. so you can run it. the PACMAN attack using a PACMAN gadget (a snippet of victim code that can be used to carry out the PACMAN attack). “
Last year, Hector Martin, founder and project manager of Asahi Linux, reported an M1 crash called M1RACLES that was not particularly consistent. He also alluded to a second CVE affecting the M1 that was not released.
Ravichandran said he and his colleagues had only found this defect affecting M1.
“We investigated the M1 chip as it is the first desktop CPU to be shipped with pointer authentication,” he said. “We reported all of our findings to Apple last year, but we don’t know if they mitigated anything or not.”
The paper discusses possible PACMAN mitigations, such as stopping speculative execution with access to memory and branch instructions, but notes that doing so may affect performance.
Ravichandran said he could not say whether Apple’s new M2 chip could be vulnerable because researchers have not had a chance to investigate it.
“We believe that future CPU Arm with pointer authentication and speculative execution may also be vulnerable to PACMAN attack.”
The registry asked Apple if it had addressed PACMAN on its M1 or M2, but we have not received a response.
The PACMAN paper is scheduled to be presented at the International Symposium on Computer Architecture in New York City on June 18. ®