M1 Chip Vulnerability

This is a new vulnerability against Apple’s M1 chip. Researchers say that it is unpatchable.

Researchers from MIT’s Computer Science and Artificial Intelligence Laboratory, however, have created a novel hardware attack, which combines memory corruption and speculative execution attacks to sidestep the security feature. The attack shows that pointer authentication can be defeated without leaving a trace, and as it utilizes a hardware mechanism, no software patch can fix it.

The attack, appropriately called “Pacman,” works by “guessing” a pointer authentication code (PAC), a cryptographic signature that confirms that an app hasn’t been maliciously altered. This is done using speculative execution—a technique used by modern computer processors to speed up performance by speculatively guessing various lines of computation—to leak PAC verification results, while a hardware side-channel reveals whether or not the guess was correct.

What’s more, since there are only so many possible values for the PAC, the researchers found that it’s possible to try them all to find the right one.

It’s not obvious how to exploit this vulnerability in the wild, so I’m unsure how important this is. Also, I don’t know if it also applies to Apple’s new M2 chip.

Research paper. Another news article.

Tags: , , , , ,

Posted on June 15, 2022 at 6:05 AM • 23 Comments

Comments

BrooksT • June 15, 2022 8:44 AM

The reporting on this has been terrible. It’s not really an Apple flaw, and it’s not a vulnerability so much as a flaw in a security feature.

The design flaw is in the ARM v8.3 architecture, and it just happens that the M1 is the only commercial chip on that architecture at this time. When other v8.3 systems ship, they’ll have the same flaw.

And the flaw, if exploited, just defeats pointer authentication codes. By itself it doesn’t get you anything, there has to be another vulnerability that PAC would have prevented.

In effect, it invalidates PAC and renders ARM v8.3 no more secure than v8.2. But v8.2 (and older) is all anyone has outside of the M1. So… an upcoming security advance will be a dud. But we’re no worse off, and there is no exploitable vulnerability here.

Yeah, it sucks. But not in the way most of the reporting claims.

Ted • June 15, 2022 9:35 AM

I love that – on the record – Apple is not overly worried about this vulnerability.

How fun for them that this research was in part funded by the National Science Foundation and by the U.S. Air Force Office of Scientific Research (AFOSR).

I keep seeing that the PACMAN attack needs a memory corruption bug to work. Is this at the OS level or any application? Also from the paper:

We test our tool on the release version of the XNU kernel used by MacOS 12.2.1 (xnu-8019.80.24) and find 55,159 potential PACMAN gadgets… Thus, we conclude PACMAN gadgets are readily discoverable in large PA-enabled codebases.

I like that the paper gives examples of how the attack can work. There’s at least one helpful example under Section 4.4.

Clive Robinson • June 15, 2022 10:51 AM

@ BrooksT,

The reporting on this has been terrible. It’s not really an Apple flaw, and it’s not a vulnerability so much as a flaw in a security feature.

Yes the reporting is not as good as most would like…

As originaly reported,

Apple had taken an ARM design and modified it for their own use, stripping out certain features not all of which were publically known.

It was therefore I guess assumed, because no other ARM chip was involved, it was something Apple had done (as this sort of thing has happened before).

Whilst it is a new “security detection” rather than “enforcment” feature that is being abused, it does alow an attacker to evade the new protection offered, which is undesirable. Because if it’s considerd important enough to devote silicon real-estate to, then the designers have reasonable suspicion it is going to prevent security failings.

Whilst software it’s self may not fix it, detecting that an attacker is trying to thwart it should be possible to a degree.

But that brings into question the cost not just in changes to be made but what to do with false positives or attackers finding ways to bypass the detection in new ways (which almost certainly will be found, such is the nature of such things).

It is a mess and to be honest it’s just one of many based around the various speculative execution mechanisms, which regularly turn up new vulnerabilities.

Some would say “strip it out” with regards speculative execution, but it is one of the “go faster stripes” that does make a noticable improvment outside of specmanship code.

The trick is to have speculative execution of security features happen in an “out of band” way. So that the result can not be provoked and “soft tested” by visable side effectcts, thus avoided by specialised techniques. That way only “hard fails” happen, the way they are supposed to do for the security mechanism.

How you might even attempt to go about that is very much an open question, so we do not know if it can be practically done.

Clive Robinson • June 15, 2022 11:12 AM

@ Bruce,

This attack to find 16bits, reminds me of Mat Blaze’s attack against the LEAF in the Clipper chip…

That was what thirty years ago?

lurker • June 15, 2022 4:02 PM

@Clive Robinson

Some would say “strip it out” with regards speculative execution . . .

Of course it would be too confusing to have two kinds of chips, one plain simple processor designed specifically for crypto functions, which generally don’t need warp speed; and a turbo-charged version for gaming, &c. It was games that drove the need for speed, now a lot of their crunching is done in gpu.

Clive Robinson • June 15, 2022 6:44 PM

@ lurker,

… it would be too confusing to have two kinds of chips, one plain simple processor designed specifically for crypto functions…

In the case of this particliluar ARM new security feature, I don’t think crypto as such is the concern. But stopping ordinary users getting access to other process space especially privileged space via “in memory pointers that have been modified during malware execution.

I don’t know enough about the actuall ARM mechanism but I get the impression that the upper 16bits of addressss of the pointer are used as a “checksum tag” to detect in the euntime memory if the pointer has been “corrupted” in some way.

As such it’s a nice idea and a cheap way to get an aproximation to “Capability Hardware Enhanced RISC Instructions”(CHERI)[1] like “tagged memory”.

[1] https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-faq.html

Ted • June 15, 2022 8:14 PM

@BrooksT

…and there is no exploitable vulnerability here.

How so? If you can bruteforce the PAC via a micro-architectural side channel, aren’t they saying you can then conduct a control-flow hijack?

It’s pretty remarkable that the research team went so far as to create PacmanOS – described as a “bare-metal execution environment written entirely in Rust that can boot directly on M1.” It looks like they’re using PacmanOS to help with reverse engineering. The researchers add: “We believe PacmanOS will serve as a useful tool for further study of M1 and future Apple Silicon devices.”

Quizly • June 15, 2022 9:05 PM

At a certain point, researchers finding obscure clever vulnerabilities are just helping hackers and the intelligence services of opponent nations. One successful hack-attack against us, using a vulnerability discovered by our own researchers, and Congress will make this type of research criminal. And maybe they should. What is the benefit to finding an unpatchable vulnerability? Well, whether they should or not, it will happen. Politicians have a hard time following complex arguments in favor of this type of research. It’s just simpler and easier to make it illegal, as it is perceived to harm the nation.

lurker • June 15, 2022 9:26 PM

@Quizly, “What is the benefit to finding an unpatchable vulnerability?”

To use that worn out analogy, if it was a motorcar it would be off the road in the eye of a wink, and the Co. directors being measured for orange jump suits.

Computers have become so much a part of daily life it’s about time similar rules were applied as for other hardware in public spaces. Yes, the internet is a public space. And the excuse we need to keep some bugs so our own spooks can spy on us is wearing thin. . .

Gert-Jan • June 16, 2022 6:19 AM

What is the benefit to finding an unpatchable vulnerability?

In this case, it tells the buyer that the security feature is unreliable. Next is to decide whether or not to keep using the security feature.

After that we can talk about fixing the issue. Why restrict the fixing process to software patching? That’s just silly, since we’re talking about a hardware issue here.

Of course such research should be allowed. This way vendors are informed (hopefully in a responsible manner) and can fix the issue before criminals or governments start exploiting it on a large scale. And uses are informed, so they can pressure the vendor to fix the issue. It’s naive to think that in time, criminals / governments wouldn’t find the same issue, wreaking havoc.

Ted • June 16, 2022 7:15 AM

@Gert-Jan

Next is to decide whether or not to keep using the security feature.

I don’t know if this is really a straight-forward option? According to the paper, Pointer Authentication is projected to be even more widely adopted in the future, including by ARM, Qualcomm, and Samsung. From what I can tell, this feature is written into software and would still detect and prevent attacks, although maybe not PACMAN attacks at this time.

Why restrict the fixing process to software patching? That’s just silly, since we’re talking about a hardware issue here.

I believe this vulnerability exists within the overlap of memory corruption vulnerabilities and micro-architectural side-channel vulnerabilities. On https://pacmanattack.com/ it looks like they call it a hardware/ software co-attack. The paper also has a section on countermeasures, although none seems to be an overwhelmingly simple fix.

SpaceLifeForm • June 17, 2022 6:03 PM

@ Gert-Jan, Ted

Next is to decide whether or not to keep using the security feature.

It is not a Security Feature for you, the user. As the user, you will have no choice in the matter as you cannot control the silicon.

It is a Security Feature for Apple, that will not work. This alleged defense is really for Apple to discern when the kernel is under attack.

Since this defense is exploitable, it is just Security Theatre.

At this point, it is just wasted microcode overhead, wasted cycles.

It might throw a HertzBleed attacker off the trail for a bit. But, I doubt it.

Ted • June 17, 2022 8:30 PM

@SpaceLifeForm, Gert-Jan

Since this defense is exploitable, it is just Security Theatre.

I certainly get what you’re saying. It looks like this group has been in talks with Apple since 2021. So I can’t imagine that Apple’s engineers have been sitting idling by watching their security investments go up in flames.

An update would be awesome, yes?

I don’t know how many memory corruption bugs are typically in an Apple kernel, seeing as this attack requires one. In the demo attack, they added a “kext” (a custom kernel extension) to the kernel. This allowed them to introduce an artificial software bug to the kernel, and also a PACMAN Gadget.

An attacker would have to find their own kernel bug to exploit.

I’m the furthest thing from an expert on all the details here, but at least we might be a little less caught off guard when more security features roll out.

Another odd thing is that the researchers said it took 2.94 minutes for their brute-force attack to test all the possible PAC values. That’s like forever.

Clive Robinson • June 17, 2022 11:23 PM

@ SpaceLifeForm, ALL,

It is a Security Feature for Apple, that will not work. This alleged defense is really for Apple to discern when the kernel is under attack.

Is it “for Apple” or “supplied by ARM” as standard?

As I’ve said above it’s not altogether clear who came up with this idea and put it in the silicon.

The next issue is one of those awkward ones.

As I’ve pointed out in the past “security is not inherent” you have to build it in one component at a time. That is you can not pick a resiator, capacitor, transistor etc that are “secure” there is no such thing… You have to build inherently insecure components into a moderately complex system to start getting some level of security.

The implication is that security at any given level is not perfect, and requires a certain level of complexity. That is,

“Walls alone do not make a house, but you can not make a house without them”

Likewise the foundations that support them.

So the question arises as to if the components you are building this particular complexity from are being used in an effective manner for the level of security you get from them?

Part of that calculation is the dred “reuse”, based on multi-use. We already know that the otherwise unused 16bits of the pointer are being used as a “check-tag”.

Arguably as I noted further up 16bits is probably insufficient in some respects. But what would be the cost of adding one more bit? Well you’ve two options,

1, Take the system bus width from 64 to 65 bits…
2, Half the amount of memory available by going from 48 to 47 address bits.

Neither appears to be particularly viable.

Thus the next question is how much extra silicon real-estate is needed?

That rather depends on how much is specific, or reuse, from other lower level functions, that are required for other features.

It could be a little “glue logic” or a massive amount of highly specific logic. So comes in a range from near zero extra cost, or a great deal. As far as I’m aware we’ve not been told this… So can not make judgment calls, but I would suspect it’s not that high cost.

You then have to go into value for money estimates, which again I’m not aware of there being sufficient information.

If anyone does know some pointers to the information would be handy.

SpaceLifeForm • June 18, 2022 1:10 AM

@ Ted

LOL

Another odd thing is that the researchers said it took 2.94 minutes for their brute-force attack to test all the possible PAC values. That’s like forever.

According to my relativistic calculations, that is like 183829787234 nanoseconds. That seems excessive, no? This exploit should not take that long. The attacker should be able to save a few nanoseconds by lowering the temperature.

Clearly, we owe each other a virtual beer. Cheers!

An attacker would have to find their own kernel bug to exploit.

Not when you can control the SIM, or the Baseband Radio, or the WIFI/Bluetooth, or the GPU, that all have access to the RAM via unsecured I2C bus.

It is all Silicon Turtles. See Pegasus.

SpaceLifeForm • June 18, 2022 1:55 AM

@ Clive, ALL

Is it “for Apple” or “supplied by ARM” as standard?

As I’ve said above it’s not altogether clear who came up with this idea and put it in the silicon.

It was an Apple decision. They have full license. They have the money to try to twist an ARM. But ARM does not have to cry Uncle over this.

Apple has the license to screw up their silicon as much as they want. Assuming they have the fab to do so.

You are no under obligation to use screwed up silicon.

You do not need to even look at Bad Apples.

From 2008:

hxtps://appleinsider.com/articles/08/07/30/arm_reports_finger_apple_as_long_term_architecture_licensee

From 2015:

hxtps://news.ycombinator.com/item?id=10190521

Clive Robinson • June 23, 2022 11:51 AM

@ Security Sam,

Me thinks Bruce swiped both the cup and the Tea Pot!

Well “me old china”, I guess that leaves the saucer and spoon. But there does appear to be as they say “no rhyme, or reason”… But as Shakespeare had Prospero enquire,

“Hast thou, spirit,
Perform’d to point the tempest that I bade thee?”

Security Sam • June 27, 2022 10:27 PM

And as Chaucer recited:

“Hardy he was and wys to undertake;
With many a tempest hadde his berd been shake.”

Clive Robinson • June 28, 2022 3:25 AM

@ Security Sam,

Re : Tempest

So “Old school” quotes now 😉

Or atleast my old school for “Chaucer”.

So a Chaucerian sermon in four quotes,

“Time and tide wait for no man”

So,

“By nature, men love newfangledness.”

Which is why perhaps,

“The greatest scholars are not usually the wisest people.”

And sadly,

“People can die of mere imagination.”

Security Sam • June 28, 2022 7:31 AM

@Clive Robinson

Heeding the timeless advice:

“I wish to resume my watch by the sea against wrathful hosts!” -Beowulf

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.