PACMAN Attack on M1 Processor
Carly Page (Hacker News, paper):
The attack, appropriately called “Pacman,” works by “guessing” a pointer authentication code (PAC), a cryptographic signature that confirms that an app hasn’t been maliciously altered. This is done using speculative execution — a technique used by modern computer processors to speed up performance by speculatively guessing various lines of computation — to leak PAC verification results, while a hardware side-channel reveals whether or not the guess was correct.
What’s more, since there are only so many possible values for the PAC, the researchers found that it’s possible to try them all to find the right one.
[…]
The researchers — which presented their findings to Apple — noted that the Pacman attack isn’t a “magic bypass” for all security on the M1 chip, and can only take an existing bug that pointer authentication protects against.
Other researchers familiar with PACMAN say that how dangerous it really is remains to be seen. However, PACMAN “increases the number of things we have to worry about when designing new security solutions,” says Nael Abu-Ghazaleh, chair of computer engineering at University of California, Riverside, and an expert in architecture security, including speculative execution attacks. Processors makers have been adding new security solutions to their designs besides pointer authentication in recent years. He suspects that now that PACMAN has been revealed, other research will begin to find speculative attacks against these new solutions.
Yan’s group explored some naive solutions to PACMAN, but they tended to increase the processor’s overall vulnerability.
[…]
“People used to think software attacks were standalone and separate from hardware attacks,” says Yan. “We are trying to look at the intersection between the two threat models. Many other mitigation mechanisms exist that are not well studied under this new compounding threat model, so we consider the PACMAN attack as a starting point.”
Our goal is to demonstrate that we can learn the PAC for a kernel pointer from userspace. Just demonstrating that this is even possible is a big step in understanding of how mitigations like pointer authentication can be thought of in the spectre era.
We do not aim to be a zero day, but instead aim to be a way of thinking about attacks/ an attack methodology.
The timer used in the attack does not require a kext (we just use the kext for doing reverse engineering) but the attack itself never uses the kext timer. All of the attack logic lives in userspace.
Provided the attacker finds a suitable PACMAN Gadget in the kernel (and the requisite memory corruption bug), they can conduct our entire attack from userspace with our multithread timer. You are correct that the PACMAN Gadget we demonstrate in the paper does live in a kext we created, however, we believe PACMAN Gadgets are readily available for a determined attacker (our static analysis tool found 55,159 potential spots that could be turned into PACMAN Gadgets inside the 12.2.1 kernel).
The design flaw is in the ARM v8.3 architecture, and it just happens that the M1 is the only commercial chip on that architecture at this time. When other v8.3 systems ship, they’ll have the same flaw.
Previously:
- Apple Silicon “Augury” DMP Vulnerability
- M1racles: M1ssing Register Access Controls Leak EL0 State
- Intel CPU Design Flaw Necessitates Kernel Page Table Isolation
