PACMAN, the unpatched security problem of the Apple M1
So far, the Apple M1 microprocessor has only brought delight to Cupertino. Since its introduction approximately a year and a half ago, both the first of Apple Silicon's first-generation chipsets and its "big brothers," the Pro, Max, and Ultra variations, have received glowing reviews, demonstrating that the engineering effort involved in building their own chips is truly extraordinary.
However, it had to be during the week when the long-awaited Apple M2 was unveiled, and specifically on the day that rumors regarding the forthcoming M2 Max came, that it was revealed that the Apple M1 has a security flaw. Although it does not affect users of devices using this chip, it is a severe message to Apple, as well as other integrated designers, about the hazards of ignoring security during the chip design phase.
Researchers from the Massachusetts Institute of Technology's Computer Science & Artificial Intelligence Laboratory (CSAIL) created PACMAN, a proof of concept that consists of a mixed attack capable of exploiting a vulnerability discovered in the Apple M1's Pointer Authentication Code (PAC), which normally protects the device from exploiting issues related to memory corruption processes.
PAC assigns a cryptographic signature to each memory pointer in regular operation, which is used to securely validate them before they are used. Saving the distances, we can compare each of PAC's signatures to the HASH codes, allowing us to believe what is linked with it. Thus, in principle, the Apple M1 would be safe from assaults that attempted to modify the pointers for nefarious purposes.
The MIT researchers discovered a flaw in the implementation of PAC in that there are only a limited number of potential values for the signature, therefore they attempted to exploit this weakness of the Apple M1 supported by speculative execution (a technique that allows deducing certain points). It would be possible to significantly reduce this list, allowing all options to be examined until the correct one is found.
PACMAN alone would not be enough to create an assault against an Apple M1-based system; it would need to be combined with other factors. However, as previously stated, it is an indication that the signature validation provided by PAC may be insufficient, and the CSAIL recommends engineering teams consider this issue in future designs.
Apple has acknowledged the issue and acknowledges and appreciates the work of MIT researchers. However, it is unclear whether this issue can be reproduced on the Apple M2 (which also employs PAC for pointer validation), which is disappointing but understandable. The key, of course, will be to see if the Apple M1 vulnerability is mitigated in future Cupertino SoCs, which we will have to wait to see.
