MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips
techcrunch.com
techcrunch.com
https://spectrum.ieee.org/pacman-hack-can-break-apple-m1s-la...
(via https://news.ycombinator.com/item?id=31694844 and https://news.ycombinator.com/item?id=31694017, but we merged the latter hither and the former had no comments)
This is interesting theoretically but the amount of access required is pretty high, this is hardly an exploitable zero day.
Having read the paper, in a nutshell it requires:
- Login to the Mac in question
- Ability to install a custom kext to make the PACMAN Gadget work. The exploit requires access to undocumented registers on the M1 that are apparently not accessible from user space, but this is a bit unclear.
- Also need an exploitable kernel buffer overflow against Mac OS (they made a custom kext with a buffer overflow)
- Run the bufferflow + Pacman Gadget together to do the final elevation
If someone can find a way to do this without installing kexts then it becomes way more serious. As is it certainly is a super interesting paper and presents a bunch of work for chip designers.
So ultimately, right now, it's just downgrading a very new protection to as if it didn't exist, which is exactly how 98% of ARM chips in the world operate right now. Not great, not terrible, A for effort, was worth a shot, speculative execution breaks everything.
Our goal is to demonstrate that we can learn the PAC for a kernel pointer from userspace. Just demonstrating that this is even possible is a big step in understanding of how mitigations like pointer authentication can be thought of in the spectre era.
We do not aim to be a zero day, but instead aim to be a way of thinking about attacks/ an attack methodology.
The timer used in the attack does not require a kext (we just use the kext for doing reverse engineering) but the attack itself never uses the kext timer. All of the attack logic lives in userspace.
Provided the attacker finds a suitable PACMAN Gadget in the kernel (and the requisite memory corruption bug), they can conduct our entire attack from userspace with our multithread timer. You are correct that the PACMAN Gadget we demonstrate in the paper does live in a kext we created, however, we believe PACMAN Gadgets are readily available for a determined attacker (our static analysis tool found 55,159 potential spots that could be turned into PACMAN Gadgets inside the 12.2.1 kernel).
Our paper is available at our website: https://pacmanattack.com/paper.pdf
Most of the mainstream articles make it seem like they a) did not read the paper b) are incapable of understanding the paper c) were not provided any guidance about what any of this actually means in the real world.
Which is all scary as the paper is well written and very accessible IMO.
I don't see anything wrong with that, because all opinions are not equal.
I think there is some level of pressure to get one's word in quickly, otherwise the nebulous cloud of commenters moves on to the next story, and your well-thought-out comment that took hours to write is seen by no-one. If you're responding to someone hoping to get into a nice conversation, you're out of luck since they have no idea you just responded to them.
It’s a very diplomatic choice. Moreso than I’d have gone with. I admire your restraint!
"Apple is DOOMED!"
"Turn off your iPhone, Apple's security BUSTED!"
I would take anything Matthew Green blogs about with a grain of salt. It's not clear how much of what he says is just cheap amplification of what others claim.
Yeah, that's a given. Journalists do not have time for optional tasks.
b) are incapable of understanding the paper
That's a safe bet.
c) were not provided any guidance
Asking for guidance or clarifications is another one of those optional tasks.
The article is pretty good and shows good understanding of what the attack is.
> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.
But what can you do about it?
This seems pretty par for the course in terms of science/tech journalism to be honest.
But reading your comment does sort of put a smile on my face though. The what others would called a non-cynical world view.
The headline is pretty reasonable too. Apple can't patch this, and as other commentators point out subsequent attack techniques are only going to make this flaw worse.
> Something definitely went wrong here though
Both of these have the same reason: it's about Apple. I know someone that avoids telling people that they work at Apple, to avoid similar drama.
Or do they have strong limits as well?
The full fix will require a complete recompile of the full kernel/toolchain, if they can do any kind of microcode update (I have not checked) that allows for mitigation.
Then the extension needs to be allowed in System Preferences > Security (this step has been required on Intel Macs too)
/s, though not entirely, moving more stuff to unprivileged contexts would be nice
But yes, there was a time when editing even /etc/sudoers required disabling SIP. That time is long gone.
reading the "official" site of the Researchers gives more clues than the headline of the article.
right, ok? as Snowden thankfully heroically warned us, the NSA already has root-level access to most devices.
“ Remember the Spectre vulnerability. Now we have more than 7 variants of Spectre. No one guarantees that new, more destructive versions of this vulnerability will not be discovered in the future.”
> If someone can find a way to do this without installing kexts then it becomes way more serious.
right, yeah, you’re onto the right trail now.
Really? Usually malicious stuff is installed by the user themselves being unaware of it.
This is attacking a memory safety exploitation mitigation tech, there needs to be a memory safety bug. Otherwise there's no need for PAC in the first place.
^ This is not the case, you can trigger these from userspace in valid syscalls. The same behaviour was in spectre.
Here's a link to the actual abstract. The work will be presented at ISCA, which will start on June 18. https://dl.acm.org/doi/10.1145/3470496.3527429
Here's a link to MIT's press release. https://www.csail.mit.edu/news/researchers-discover-new-hard...
Here's a link to the vulnerability's website, as is tradition now. (Plus the paper) https://pacmanattack.com/
I believe that the researchers have found a way to remove PAC as a barrier to exploitation by disclosing PAC verification results via speculative execution. This is only useful to attackers going after a target that uses PAC, and those attackers will need to have another vulnerability that enables them to hijack control-flow through modifying pointers to code that are located in memory.
The attackers can use this new Pacman vulnerability as a crash-free oracle that says whether their forged pointer worked, and once they find a working one, they can use that to hijack control flow.
PAC (or Pointer Authentication) is a security feature found in recent iPhones, the Apple Silicon Macs, and the Graviton3. It is intended as a defense against control-flow hijacks. It works by signing pointers found in memory with one of five keys that are known only to the processor. Before the pointer is used, the processor should be instructed to "authenticate" the pointer by checking the pointer's signature using its private keys. To prevent simple reuse of one authenticated pointer used in one place to a pointer used in another place in the program, code can provide a "context" value to be used during the authentication.
A great resource for learning about PAC and its usage in the Apple platforms is at [1] (it links to other resources) and if you want to play with a PAC enabled binary, check out [2]
[1]: https://googleprojectzero.blogspot.com/2019/02/examining-poi...
[2]: https://blog.ret2.io/2021/06/16/intro-to-pac-arm64/
EDIT: The attack works by:
1) Place your guess such that it is used as the pointer input to an authentication instruction
2) Causing a branch misprediction. On the not-taken side of the branch, code needs to perform a pointer authentication and usage of the pointer. On the taken side of the branch, code should not crash.
3) CPU speculatively executes down the not-taken side of the branch (misprediction) and speculatively executes the authentication instruction.
4) If your guess is correct, the authentication instruction will return a valid pointer. If your guess is incorrect, the authentication instruction returns a pointer that, if dereferenced, will cause an exception.
5) CPU speculatively executes a load (in the case of a data pointer) or an instruction fetch (in the case of a code pointer) on the pointer value.
6) If the pointer is valid, the address translation for that pointer will appear in the TLB. If the pointer is not valid, it will not (because of the exception).
7) All of the effects from this mispredicted branch get squashed when the CPU realizes that the branch is not taken. No exception is actually thrown!
8) Measure the TLB entries to determine whether the speculative address translation made it in. If it is present, you know that the guess is correct.
9) Repeat, up to 2^16 times.
Who can guess at the performance impact, but one could imagine a configurable mechanism capable of disabling speculation past a PAC authentication.
I would have added that as a potential mitigation in the mitigations section. I think, say, changing the key every so often would be a reasonable task for a kernel to do, especially in the timeframe that this was exploited (about 3 minutes)
However, context values are not something that is supported by any C ABI: the PAC extension contains also instructions that hardcode the context value to zero, and I would guess that those are what the kernel is using currently. To make use of context values, I suppose you would have to use a new ABI that stores effectively 128-bit pointers, and which also creates the random nonces/keys/whatyoucallthem to store in them.
The root of the problem is the small hash size and the fact that you can "suppress" failed hash check effects to bruteforce the hash. (it's expected that a failed hash check will cause a crash, which was intended to prevent bruteforcing)
I get the performance gainz, but when are we going to get past the formal fallacy that executing any instruction we don't need to based on actual flow is de facto a complete violation of user expectations and therefore completely unsafe to do.
Like every lay person I explain speculative execution seems to be able to recognize that a pipeline stall to figure out what a value actually is just the way to go.
Hell, my personal sanity check with computing is that there must exist a humans only implementation that correlates to a good computing primitive.
Nowhere on Earth, will you find an organization that will execute both sides of a conditional process requiring hunans to do the work just to throw away the result. Not taken.
Oh wait... Finance does it with Hedges...
Frigging finance. Ruins everything for everyone.
Speculative execution today (within modern high-end processor) does not execute both sides of a conditional branch.
It would indeed be a waste of power and it would be a much more complex micro-architecture.
Modern speculative OoO processors execute a single path and simply relies on the branch predictor accuracy. And they are pretty accurate, on the order of 3 misspredictions every 1000 instructions. The power consumption in unnecessary work due to a missprediction is quite low.
Modern processors consume much of their power in Out-of-Order instruction scheduling.
As I was fairly sure that as many computations were done as possible in the same cycle with the ditching of "not the case" results on subbsequent cycles, but I'll be the first to admit I haven't synced on the bleeding edge lit recently. And sipping power has become much more of a concern in recent years, do I may be due for a refresh anyway.
My favorite past time if the statistics are to be believed.
How lawyer-y do you think Bandai Namco will be?
Not saying that's what this is (I'm sure these are legitimate findings), but this tactic raises some red flags for me.
1: https://www.gamersnexus.net/industry/3260-assassination-atte...
Maybe this "unpatchable flaw" with the M1 has some more legitimacy than the "critical AMD vulnerabilities" back in 2018, but please, stop with the stupid trendy names for vulnerabilities. Lets discuss this on the technical merits and skip the marketing.
How many important security vulnerabilities have just had technical white papers and no marketing have gotten wider coverage? Very, very few. It’s also very useful for humans to talk about something when given a short, memorable name.
It is not a trend. It's a tradition:
Back Orifice. Ping of Death. Smurf Attack. Computer Viruses. Computer Worms. (Hello Robert Morris!)
How does one prove that a hardware exploit is actually 'unpatchable'?
Thanks
In practice, both of these would probably kill performance, so I don't think either of these are great solutions. Recall we are targeting the kernel where everything needs to be as fast as possible.
2 questions.
1) it's relatively known that PAC is brute-forcable given its relatively small key space (16 bits, sometimes 8 if TBI is enabled). How does your attack differ from general brute forces? (My impression is just your leveraging of the BTB/iTLB is a bit more stealthy.) Similarly, in your opinion, would a fix be more ISA-level or you think it's more specific to the M1 (given brute forcing in general is a PtrAuth problem)?
2) you mention in section 8 that this took 3 minutes for a 16b key and tons of syscalls. Wouldn't another proper mitigation be to limit the number of signatures per key? 3 minutes is definitely a long time, and some form of temporal separation may be quite helpful.
1) Our attack does apply a brute force technique with the twist that crashes are suppressed via speculative execution. If you tried to brute force a PAC against the kernel, you'd instantly panic your device and have to reboot.
2) Given that we never sign anything (only try to verify a signed pointer), and that every authentication attempt happens under speculation, I'm not sure how you would rate limit this without absolutely destroying performance. Keep in mind the kernel is doing a whole lot more with PAC than just our attack (for example, every function's return address is also signed with PAC) so distinguishing valid uses from a PACMAN attack might be challenging.
I suppose you could track how many speculative PAC exceptions you got, but it's a little late to add that now isn't it? And it could also raise lots of false positives due to type confusion style mechanisms on valid mispredicted paths.
Third Q-- What's your opinion on BTI as a possible mitigation? Given it's an v8.5 feature meant for JOPs, and this attack is essentially a speculative JOP, maybe we could use BTI to mitigate and heavily reduce the number of gadgets, speculative or not.
User mode software requires a TLB (unless you want to do a page walk for every single instruction!)
Even if you could remove the TLB entirely from the CPU somehow, the attacker could just use the cache or some other microarchitectural structure.
I never have to worry about such low level details in my day-to-day work, so this is all new to me.
A colleague pointed out that FPAC[1] in ARMV8.6-A likely prevents this attack, is that right?
I haven't fully digested the paper, but the gadgets seem to rely on AUT, and "Implementations with FPAC generate an exception on an AUT* instruction where the PAC is incorrect"
[1] https://community.arm.com/arm-community-blogs/b/architecture...
(There are a few aspects that make this challenging in practice, but that's the idea).
This vulnerability it's useless by itself.
It's like if I could wave a magnet over your encrypted backup tapes, ruining your restore capability, but without having any ability to affect your production and DR sites. You'd rather it didn't happen, but you are still up and even have redundancy.
today, how many years it took the theory to be applied in "real world" with other cpu vulns
This will not become Spectre-like in 10 years from now.
The impact will be the same as it is today.
Infosec isnt just home runs, it is iterative, cumulative progress toward a shared goal. things like this are what ultimately led to XBox and Playstation jailbreaks.
This is a vulnerability that reduces the security of the Apple Silicon platform to being closer to on par with the immediate prior platform that Apple is actually still selling.
Definitely an impressive result, and it certainly reduces the usefulness of PAC, but I'd guess PAC is still going to prevent a significant number of attacks.
>does PACMAN have a logo? >Yes!
great, answering the hard questions.
the trend of creating a marketing website for every horrible exploit is so strange. Who are these people selling to, and what?
Fear to media outlets is my only guess.
It’s not a given that the speculative PAC gadgets in any kernel are exploitable as effectively as the synthetic kext gadget in the paper.
Even if you find a weaponizable PAC gadget in the kernel, and it actually gives you what you want, it’s not clear how reliable it’ll be in practice.
So, this is kinda scary but it’s also a bit of theatre. The tech press will have something to write about though.
Prior speculative execution issues applied to more than one vendor's implementation.
It remains to be seen whether their implementation is better.
Until now only few people had access to such recent CPUs, which can be found only in the 2022 models of some smartphones and in the new Graviton 3 servers, so they did not receive much scrutiny.
Hahah, ok now I have a much better understanding.
It requires an existing path to arbitrary code execution, and a buffer overflow or some such in kernel space.
So yes this does defeat one part of the M1 defensive system, which is clearly suboptimal, but the way the article portrays it is absurd.
Spreading paranoia is how the security industry has always operated. It is its incentive, after all.
* A few years old now I guess
The attack itself however seems like it’s fairly close to requiring true arbitrary code execution (the earlier spec. Execution bugs could be unit from “correct” JS).
Nevertheless, the article is very important, because it shows that this supposedly security-improving feature has been implemented in a way that makes it useless (like it has also happened with some Intel security features, e.g. Software Guard Extensions).
Everybody must become aware that this "pointer authentication" feature is currently unreliable, so it must not be used, and the designers of future CPUs must take care to not repeat these mistakes.
I would think it can’t harm, ever.
Nevertheless, there is some small loss of performance, because instructions to compute the Pointer Authentication Code (PAC) must be inserted in the program, and possibly also instructions to authenticate the PAC, though the latter may be omitted if the function return instructions and the indirect jumps through pointers are replaced with instructions that combine the pointer authentication with the jump.
I have no idea whether on the Apple CPUs the jumps/returns with authentication have the same speed with the simple jumps/returns.
I suppose that the Apple compiler adds automatically the PAC computation and authentication instructions, so using this option does not increase the complexity of the source code.
Nevertheless, even if the performance impact of using PAC might not be important, whenever a security feature that does not work is used, there is the danger that there will be some people who do not know that it does not work, so they will believe that exploits are impossible and there is no need to be careful to avoid the possibility that an adversary might be able to modify a pointer, e.g. by crafting a special input to the application.
In general all the variants of pointer validation that have been recently introduced in all CPU architectures are just workarounds against the bugs introduced by programmers, because in a well written program there should be no way for an adversary to modify an internal pointer.
Any decent C/C++ compiler has compile options to check all array accesses against limits, which, coupled with the good programming practice of always using indices and not pointers for memory accesses, can catch all the programming errors of the buffer overflow type.
However, neither the compilers enable this option by default nor most programmers take care to always enable it, because of usually baseless worries of degrading the performance.
Checking accesses against limits catches any such bugs at their origin, not much later when a corrupt pointer is identified by PAC, without knowing how it became corrupt.
Intel has made an attempt with Skylake to introduce some instructions for easier limits checking, but unfortunately the instructions conceived by them were just dumb and not helpful at all, so they have been eventually deprecated.
Better support exists in the IBM POWER ISA, which has conditional trap instructions.
Sounds like a huge deal if you want to run untrusted code inside a sandbox.
IOW, not gonna happen.
I could see coprocessors becoming more popular though. We already have AES-NI, what if the sensitive keys never ended up in CPU cache because the CPU never had to see them? Specialized HW could not have speculative execution. Granted, that doesn't prevent seeing the plain text of something that's decrypted. It's all about the threat model and what tradeoffs you're willing to make.
And that's why Intel et al haven't completely abandoned speculative execution. For the vast vast vast majority of people, the security issues they're much more likely to deal with are straight up getting scammed. Not 0 days, and especially not insane stuff like this. Unless you can turn it into a zero-click iMessage bug (or similar), meh.
Any thoughts on the above?
Such lists were initially published as "Errata Lists", but now many manufacturers use less honest names, e.g. Intel uses "Specification Update" and AMD uses "Revision Guide".
Some defects may become manifest only when the hardware is used in certain ways, which may be avoided by the motherboard manufacturers, maybe at the price of reduced performance.
Many uncorrected defects affect only various testing or performance monitoring features. Many other uncorrected defects affect only privileged programs, so the resolution "Won't Fix" is justified by saying that all the popular operating systems have been tested and they have not been seen to trigger the bug. (For someone who develops their own operating system it is mandatory to read all the errata lists, because obviously their OS will not be used by Intel and AMD for testing the new CPUs.)
When the defects can affect user programs, in many cases it is possible to implement workarounds with microcode updates included in BIOS or operating systems, possibly with the price of reduced performance. Only when no microcode workaround is possible and the bug can be triggered by user programs, leading to crashes or incorrect results, then the defect is scheduled for being corrected in a new revision of the CPU. Most of these defects that are corrected are discovered during the testing of the engineering samples, before the official launch of the CPU, which uses the latest revision, with only the known defects that either do not affect non-privileged programs or have microcode workarounds.
Note that Intel very rarely issue new revisions of existing models nowadays. Probably creating new masks is too expensive. They simply include some fixes in new models. Probably likewise for all vendors for high-perf but non-critical applications. And probably they all try to let the microcode cover more things via chicken bits or other methods, to avoid the risk of having to do catastrophic recalls.
I’m not convinced you can write a “for” loop safely on a modern processor.
Anyway, it seems those apple chips can be used not only for apple systems, which makes it a competitor to both AMD and intel?
Essentially, the attacker must have access to another buffer overflow of some sort.
This is only a bypass for a specific line of defense, called PAC - a security feature introduced recently in ARM 8.3. By itself, it is not enough to attack a system at all.
This only happens with my IPv6 landline internet connection (german carrier Telekom), via IPv4 mobile internet (T-Mobile) it loads fine. Happens with two different devices, so it shouldn't be a compromised device, Techcrunch TLS certificate is valid, so it also should not be a compromised router or my ISP. Are they A/B testing?
edit: https://spectrum.ieee.org/pacman-hack-can-break-apple-m1s-la... seems to cover the same thing with less spyware
The massive cookie wall I'm met with when opening this site makes it clear that it's probably impossible to determine which third party is responsible this time.
You can read the article safely here: https://12ft.io/proxy?q=https%3A%2F%2Fweb.archive.org%2Fweb%...
The web archive also seems to be redirected for some reason, though that might as well be intentional.
Edit: thinking about it, this might also be an attempt to use first party tracking to bypass third party cookie restrictions. Maybe they're A/B testing a new advertising tool?
It's Yahoo/Oauth's spyware domain and as the URL suggests it "collects identifiers" presumably takes a browser fingerprint and sets tracking cookies.
NB: techcrunch is basically advertising.com (via aol/yahoo/oath/verizon media/whatever else)
You can use https://github.com/StevenBlack/hosts as your hosts file, but even better is TLD and wildcard domain blocking with dnsmasq or dnscrypt-proxy.
Sending men in black or a top secret letter to a company and demanding a back door has to be the clumsiest possible way to go about introducing a vulnerability. It creates way too many people in the know, anyone could disclose it to researchers like OP who could then claim to have found it independently.
It's way more effective to have moles on your payroll.