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.
Source: securityboulevard.com
