Hacker News Re-Imagined

MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips

  • 885 points
  • 26 days ago

  • @markus_zhang
  • Created a post

MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips


@macinjosh 26 days

Replying to @markus_zhang 🎙

This is the second hardware security flaw in the M1. Was this known to Apple in time for M2?

Reply


@collsni 25 days

The Apple fanboy army is present in this conversation

Reply


@ben7799 26 days

The author is here and ought to make it all clear but if you google the title of the article you can download the paper already despite everyone being coy about it and the ACM not having published it yet. 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.

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.

Reply


@olliej 26 days

The researcher use a kext afaict solely to provide an exploitable gadget - e.g an attacker would need to find one themselves, and finding a kernel bug is not something that gets a journal publication so isn’t relevant to the research. In that case using a kext seems reasonable.

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).

Reply


@flerp 26 days

Adlink ahoy

Reply


@kurupt213 26 days

Probably an M2 vulnerability too?

Reply


@neycoda 25 days

MIT has some of the smartest tech people in the world. I wonder if some of smartest malware comes out of MIT somehow?

Reply


@pizlonator 26 days

So an attacker who needs to bypass PAC can already sometimes find a nonspeculative PAC bypass, though it’s hard. Assuming they can’t, maybe they can use this, if they can find and weaponize an appropriate gadget in the kernel. Sounds plausible but hard; maybe harder than finding a nonspeculative PAC bypass. Any speculative PAC bypass will also suffer from nondeterminism, so it’s not as practical for an attacker as a nonspeculative bypass.

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.

Reply


@ENOTTY 26 days

As someone with a bit of experience in this area, IMO, the Techcrunch article is more confusing than it should be.

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/

Reply


@frankfrankfrank 26 days

Considering all we have learned over the years, it is not unreasonable to wonder whether this “flaw” isn’t there by design to meet some secret American government vulnerability requirement.

Reply


@GeekyBear 26 days

Replying to @markus_zhang 🗣

Isn't pointer authentication a feature of the ARM 8.3 instruction set and not an Apple specific thing?

Reply


@jokoon 25 days

I guess that was a reason why the M2 was recently announced?

Anyway, it seems those apple chips can be used not only for apple systems, which makes it a competitor to both AMD and intel?

Reply


@formvoltron 26 days

ummm. Could this flaw be attacked via the web? And Apple cannot fix it?

Reply


@cosmiccatnap 26 days

I wonder at what point we will finally give up on trying to make a stable implementation of speculative execution.

Reply


@olliej 26 days

Replying to @markus_zhang 🗣

My reading implies you need actual code execution already? As you need to be able lay down the actual auth instruction that you want to force? (Eg nothing so horrific as simply running js)

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.

Reply


@calo_star 26 days

I find it so frustrating and disgusting that articles like this don't link to the original research paper/publication.

Reply


@jprx 26 days

Hi! Joseph (one of the authors) here. You can read more about our attack here: https://pacmanattack.com

Reply


@tikkun 26 days

Sounds like it requires physical access to a device, is that right? At least less of a concern than software only, though still not good.

Reply


@donkarma 26 days

Replying to @markus_zhang 🗣

Skimmed this really fast, but is this just bypassing PAC by brute-forcing the code with speculative execution?

Reply


@UncleOxidant 26 days

Replying to @markus_zhang 🗣

Since the M1 is not being used in servers, how big of a deal is this?

Reply


@BLO716 26 days

Replying to @markus_zhang 🗣

The growing pains of silicon development date back to the Intel line of Pentium FDIV bug issues. Not surprised it occurred, just surprised it took so long to come to fruition. I can only think its the lack of hardware engineers savvy enough to exploit such an issue, since the abstractions from hardware are so far removed from us general populous software developers.

Any thoughts on the above?

Reply


@dang 26 days


@schroeding 26 days

OT, but is anyone here also redirected to "https://guce.advertising.com/collectIdentifiers?sessionId=3_...", which gets blocked by µBlock Origin? It's a HTTP redirect.

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?

Reply


@serf 26 days

>https://pacmanattack.com

>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.

Reply


@josh2600 26 days

The answer, as always, is that speculative execution is the devil.

I’m not convinced you can write a “for” loop safely on a modern processor.

Reply


@ayful1 26 days

This is a great reminder that software and hardware attacks can be combined to construct better exploits. It reminds me of the attacks that used microarchitectural attacks to break ASLR/KASLR.

Reply


@api 26 days

Replying to @markus_zhang 🗣

Seems like if this were successful it would weaken the extra security provided by pointer authentication, at worse weakening it to the level of a CPU without pointer authentication like the x86_64 chips they used to use. So not great but not catastrophic. Or am I missing something?

Reply


About Us

site design / logo © 2022 Box Piper