Apple M1 Flaw Can’t be Fixed — PACMAN Panic
Apple’s M1 chip isn’t as safe from buffer overflows as previously thought. M1 and other designs based on ARMv8.3 can have their protections neutered.
MIT researchers have worked out they can brute-force the protective “pointer authentication codes” (PAC) without being detected—even in kernel memory. Once again, it’s the fault of our old friend: Speculative execution.
Their “PACMAN” technique is just waiting to help exploit the next zero-day. In today’s SB Blogwatch, we dust off our abacus.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Proof that the 12th Doctor is Rick Sanchez.
MIT ARM PAC Hack
What’s the craic? Carly Page reports—“Researchers uncover ‘unpatchable’ flaw in Apple M1”:
“The attack even works against the kernel”
The vulnerability lies in a hardware-level security mechanism utilized in Apple M1 chips … PAC. This feature makes it much harder for an attacker to inject malicious code into a device’s memory and provides a level of defense against buffer overflow exploits.
…
Researchers from MIT … have created a novel hardware attack, which combines memory corruption and speculative execution attacks to sidestep the security feature. … And as it utilizes a hardware mechanism, no software patch can fix it.
…
PACMAN works by “guessing” a … PAC—a cryptographic signature that confirms … an app hasn’t been maliciously altered. This is done using speculative execution … to leak PAC verification results, while a hardware side-channel reveals whether or not the guess was correct. … In a proof of concept, the researchers demonstrated that the attack even works against the kernel.
And take heed of Samuel K. Moore’s lore—“How many dominoes could fall if this centerpiece CPU’s weakness pans out?”:
“A side-channel trick”
At the International Symposium on Computer Architecture later this month, researchers led by MIT’s Mengjia Yan will present a mode of attack that so weakens the … PAC defense that the core of a computer’s operating system is made vulnerable. … Yan’s group explored some naive solutions to PACMAN, but they tended to increase the processor’s overall vulnerability.
…
Pointer authentication appends a cryptographic signature to the end of the pointer. If there’s any malicious manipulation of the pointer, the signature will no longer match. … PACMAN finds a way for malware to keep guessing over and over without any wrong guesses triggering a crash. … A side-channel trick involving stuffing a particular buffer with data and using timing to uncover which part the successful speculation replaces, provides the answer.
Horse’s mouth? Joseph Ravichandran, Weon Taek Na, Jay Lang and Mengjia Yan—“PACMAN: Attacking ARM Pointer Authentication with Speculative Execution”:
“May lead to arbitrary code execution”
We present … a new way of thinking about compounding threat models in the Spectre age [and] a hardware attack to forge kernel PACs from userspace. … PACMAN is what you get when you mix a hardware mitigation for software attacks with microarchitectural side channels.
…
Much like the Spectre attack our work is based on, PACMAN executes entirely in the speculative regime and leaves no logs. … PACMAN takes an existing software bug (memory read/write) and turns it into a more serious exploitation primitive … which may lead to arbitrary code execution.
…
We reported our findings and proof-of-concept code to Apple, and have been in talks with them since 2021.
Sky falling? With some important clarifications, here’s enriquevagu:
[PACMAN] does not attack Apple M1; [it] attacks a security mechanism in ARM, introduced in ARMv8.3. They have employed the Apple M1 processor … but it is very likely that many other ARMv8-based processors will have the same limitation.
…
[PACMAN] does not allow you to compromise a system by itself. ARM Pointer Authenticator Codes is a security mechanism that prevents exploiting some memory corruption vulnerabilities. With this new attack, it is again possible to exploit code that has vulnerabilities. It is the memory corruption vulnerability in the code the one that will allow attackers to compromise the system, PAC was an additional protection to prevent it.
Clear as mud? big_D tries again:
The other thing is, the ARMs (and other types of CPU) that don’t have this protection are already vulnerable to such attacks (the point of this technology is to protect the pointers from manipulations). So this attack just brings the extra protection that ARM chips with pointer protection back to a level playing field with “normal” chips.
With a “normal” CPU chip, you can manipulate the pointers directly. With these ARM chips with pointer protection, you have to additionally crack the encryption of the pointer protection in order to manipulate it. This means it is harder to get started and it takes more time than a traditional CPU without pointer protection, but once you have spent time breaking the encryption, you can manipulate the pointers, just like any other CPU.
How do we fix this? Nuke it from orbit—it’s the only way Developer12 can be sure:
“Computing must grow up”
For all the effort we put into these speed bumps, we should really be focusing on holistic, formal verification. “Last line of defense” pointer checking becomes a redundant transistor waste when pointer use is checked thoroughly at compile-time (as in Rust, but that really shouldn’t be the only example).
…
And that’s all these really are: speed bumps. There’s no such thing as “defense in depth,” because these defenses are never taken together. Attackers are perfectly happy to … bypass each new incomplete measure as it gets added. First it was stack cookies, so they focused on write primitives to copy the cookie. Then it was no-execute stacks, so they started implementing rop-attacks. And so on.
…
We’ve been collectively resistant to formal verification because it’s something that requires expertise. [But] computing must grow up, like every other engineering discipline. Civil engineering made the transition from “I think the walls should be thick enough,” to “let’s calculate the load and strain.” Electrical engineering stopped electrocuting frogs and developed Maxwell’s laws.
All of which makes splutty yearn for the days of IBM mainframes:
Modern CPU architecture are pretty much designed for performance over anything else, and security seems to be very low on the priority list. Whereas the 360/370/390 series were very much designed to be as secure and segmented as possible.
But is the reporting a bit overblown? ben7799 thinks so:
It’s kind of ridiculous it’s getting this kind of press before the paper is officially published and available. If the paper was published and security experts were allowed to analyze it before the tech press went nuts the stories would probably have a different tone.
This is interesting theoretically but the amount of access required is pretty high, this is hardly an exploitable zero day. [But] it certainly is a super interesting paper and presents a bunch of work for chip designers.
Meanwhile, skeevy420 references an older meme—but it checks out:
Yo dawg, we heard you had a vulnerability mitigator so we designed a vulnerability to mitigate your vulnerability mitigator.
And Finally:
You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or [email protected]. Ask your doctor before reading. Your mileage may vary. E&OE. 30.
Image sauce: Apple
