Light

Episode #875 Quiz

The PACMAN Attack
Date: 2022-06-14 | Length: 1.75 hrs | Episode page at twit.tv

About this episode

PACMAN exploits speculative execution against ARM Pointer Authentication on Apple M1 chips. By leaking PAC verification results through microarchitectural side channels, an attacker can brute-force 11-31-bit PACs without crashes, even from user space, and forge kernel pointers. Mitigation depends on software fixes and stronger pointer-space budgeting.

Your name and email are stored only in your browser local storage for convenience. They are not retained server-side.

NameEmail

Question 1: According to the episode, what is the key distinction Steve drew between Apple’s Passkeys approach and SQRL when it comes to sharing access with another person?

Question 1

According to the episode, what is the key distinction Steve drew between Apple’s Passkeys approach and SQRL when it comes to sharing access with another person?

Passkeys require a centralized invitation system, while SQRL only supports personal device synchronization. Passkeys are limited to local device authentication, while SQRL depends on browser cookies. Passkeys can be shared as a guest access token while SQRL cannot. Passkeys are a username-and-password replacement, while SQRL is a complete remote logon solution.

Question 2: What specific mechanism did the PACMAN researchers use to avoid crashes while still learning whether a guessed PAC was correct?

Question 2

What specific mechanism did the PACMAN researchers use to avoid crashes while still learning whether a guessed PAC was correct?

They disabled Pointer Authentication and replayed stored signatures offline. They forced the kernel to reveal PACs by logging verification outcomes in debug mode. They brute-forced PACs by crashing the victim until anomaly detection stopped responding. They used speculative execution and a microarchitectural side channel to leak PAC verification results.

Question 3: How many pointer-authentication bits did Steve say were left available on macOS 12.2.1 for M1 pointers after Apple used 48 bits for addressing?

Question 3

How many pointer-authentication bits did Steve say were left available on macOS 12.2.1 for M1 pointers after Apple used 48 bits for addressing?

16 bits 31 bits 11 bits 28 bits

Question 4: What did the researchers say about the practical visibility of a PACMAN attack if someone were trying to detect it?

Question 4

What did the researchers say about the practical visibility of a PACMAN attack if someone were trying to detect it?

It can be detected by frequent PAC failure counters in the OS. It leaves no logs because it runs entirely in the speculative regime. It produces obvious kernel panic logs that can be monitored. It is easy to spot because it requires physical access to the machine.

Question 5: What was Steve’s proposed improvement to Apple’s use of Pointer Authentication to make brute forcing significantly harder?

Question 5

What was Steve’s proposed improvement to Apple’s use of Pointer Authentication to make brute forcing significantly harder?

Increase the pointer space to 64 bits and eliminate all authentication bits. Move Pointer Authentication entirely into software and remove hardware support. Fix the issue by rotating PAC keys only when a crash occurs. Reduce the pointer space based on actual installed RAM and reserve more bits for authentication.

Cancel

My Data//Security & Privacy//Clear Local Data

© 2026 Ken ArmstrongSecurity Now™ is a trademark of TWiT LLC. All trademarks and copyrights of the Security Now podcast are respected and reserved to their respective holders.
This is a hobby project made with love and admiration for what Steve Gibson and Leo Laporte have built over 20 years.