PACMAN Attacking ARM Pointer Authentication with Speculative Execution

The PACMAN Attack

DEF CON 30 Talk

Our DEF CON 30 talk about PACMAN is now live. Check it out here!


What’s PACMAN?

PACMAN is a novel hardware attack that can bypass Pointer Authentication (PAC) on the Apple M1 CPU. We present the following contributions:

  • A new way of thinking about compounding threat models in the Spectre age.
  • Reverse engineered details of the M1 memory hierarchy.
  • A hardware attack to forge kernel PACs from userspace on M1.

PACMAN is what you get when you mix a hardware mitigation for software attacks with microarchitectural side channels. We believe the core idea of PACMAN will be applicable to much more than just PAC.

Intersection of SW and HW

PACMAN lies in the intersection of software and hardware attacks.

Read the paper here


DEF CON 30 Open-Source Release

Tool

From the beginning, PACMAN has been built with extensibility in mind.

As part of our DEF CON 30 talk about PACMAN, we are releasing our proof-of-concept attack, as well as some in-house tools we built for researching Apple Silicon devices.

We hope these tools will help the community perform next-generation microarchitectural research. For support questions, contact us at pacman-attack[at]mit[dot]edu.

Tool

Check out the code here

DEF CON 30 Talk and Slides


What CPUs are Affected?

We’ve shown PACMAN to work on the Apple M1 CPU.

Update 9/1/2022:

ARM has discovered many of its cores are also vulnerable to PACMAN. PACMAN also affects Neoverse V1, Neoverse N2, Cortex-A78C, Cortex-A78AE, Cortex-A710, Cortex-A715, Cortex-X1C, Cortex-X2, and Cortex-X3.

Who discovered PACMAN?

PACMAN was discovered by researchers at MIT CSAIL.

Co-first authors:

And:

What’s the kernel?

The kernel is the most privileged part of your computer’s operating system. Compromising the kernel means that an attacker can do anything you can do (eg. read any file, see browser data, etc.). PACMAN works across privilege levels, so it works on the kernel from user mode.

Does this attack require physical access?

Nope! We actually did all our experiments over the network on a machine in another room. PACMAN works just fine remotely if you have unprivileged code execution.

Should I be worried?

As long as you keep your software up to date, no. PACMAN is an exploitation technique- on its own it cannot compromise your system. While the hardware mechanisms used by PACMAN cannot be patched with software features, memory corruption bugs can be.

Can I tell if someone is using PACMAN against me?

Much like the Spectre attack our work is based on, PACMAN executes entirely in the speculative regime and leaves no logs. So, “probably not.”

Why are you loading a kext?

You may be wondering why our attack begins by loading a custom kernel extension (kext). This kext does two things: 1) adds an artificial software bug to the kernel for us to attack, and 2) adds a PACMAN Gadget. Neither of those things requires a kext- an attacker can find both in the vanilla kernel.

An attacker with a software bug doesn’t need a kext.

Why do you need a software bug to do the PACMAN attack?

PACMAN takes an existing software bug (memory read/ write) and turns it into a more powerful primitive (pointer authentication bypass). For our demo, we add our own bug to the kernel using a kext.

In a real world attack, you would just find an existing kernel bug.

Our demo only uses the kext for adding a software bug. The entire attack runs in userspace. So, an attacker with an existing bug could do the same attack without the kext.

Is PACMAN being used in the wild?

To our knowledge, no.

Yeah!

Does Apple know?

We reported our findings and proof-of-concept code to Apple, and have been in talks with them since 2021.


How does PACMAN work?

PACMAN takes an existing software bug (memory read/ write) and turns it into a more serious exploitation primitive (a pointer authentication bypass), which may lead to arbitrary code execution.

In order to do this, we need to learn what the PAC value is for a particular victim pointer.

PACMAN does this by creating what we call a PAC Oracle, which is the ability to tell if a given PAC matches a specified pointer. The PAC Oracle must never crash if an incorrect guess is supplied. We then brute force all possible PAC values using the PAC Oracle.

A hardware/ software co-attack.

We suppress crashes by performing each PAC guess speculatively to prevent any crashes. We then use a microarchitectural side channel to learn whether the guessed PAC was correct.

A PACMAN Gadget is a code sequence in the victim process that authenticates and tries to use a pointer speculatively. We use an existing memory corruption bug and a PACMAN Gadget to construct the PAC Oracle. The existing memory corruption bug is used to supply guesses to the PACMAN Gadget (by overwriting pointers that only get used speculatively). The PACMAN Gadget executes the test case speculatively, and we learn the results of the test via a microarchitectural side channel.

Overview

Overview of the PACMAN PAC Oracle.

PACMAN Gadgets

In principle, a PACMAN Gadget is a code sequence that uses a signed pointer speculatively. This is what a gadget looks like:

if (cond):
    verified_ptr <- aut(guess_ptr)
    load(verified_ptr)

A data PACMAN Gadget.

The attacker controls the cond variable by triggering the PACMAN Gadget in the victim (eg. by setting a syscall argument). The attacker controls the value of guess_ptr with the memory corruption bug (or, perhaps the attacker could apply a type confusion technique here).

The Side Channel

Our attack can use any microarchitectural structure as our side channel. We went with the translation lookaside buffer (TLB).

We learn whether the PACMAN Gadget was able to speculatively load the pointer or not using the prime+probe technique. We first fill the TLB with an eviction set (a minimal set of addresses required to fill up a particular set in the TLB), and then execute the test case.

We watch the TLB to see if any of our eviction set addresses are evicted. If one was evicted, then it’s likely that the load succeeded (as the loaded address kicked our address out of the TLB). Otherwise, it’s likely our guess was wrong.

Accuracy

As you will see in the paper, we find our attack is quite accurate. Here’s a comparison between the number of eviction set misses we observe using the correct PAC VS the incorrect PAC.

Accuracy Accuracy of the PACMAN Attack. (a) Data Pointers, (b) Instruction Pointers.

The X axis is the number of misses (so, the number of things in our eviction set that got kicked out during the test), and the Y axis is the number of test cases where that number of misses was observed.


Get in touch.

Want to learn more about PACMAN? Think we can improve something? We’d love to hear from you. Get in touch with us at pacman-attack[at]mit[dot]edu.

Cite PACMAN Today!

@inproceedings{PACMAN:2022,
    title = {PACMAN: Attacking ARM Pointer Authentication
             with Speculative Execution},
    author = {Ravichandran, Joseph and Na, Weon Taek
              and Lang, Jay and Yan, Mengjia},
    year = {2022},
    isbn = {9781450386104},
    publisher = {Association for Computing Machinery},
    address = {New York, NY, USA},
    url = {https://doi.org/10.1145/3470496.3527429},
    doi = {10.1145/3470496.3527429},
    booktitle = {Proceedings of the 49th Annual International
                 Symposium on Computer Architecture},
    location = {New York, New York},
    series = {ISCA '22}
}
Joseph Ravichandran, Weon Taek Na, Jay Lang, and Mengjia Yan. Pacman: Attacking ARM
Pointer Authentication with Speculative Execution. In Proceedings of the 49th
Annual International Symposium on Computer Architecture, ISCA ’22, New
York, NY, USA, 2022. Association for Computing Machinery.


Eating bits