Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips

techcrunch.com

Post reply on HN
Print view View original

31–40 of 204 posts

Re: MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips

#31

Post by dreamcompiler »

Someone wrote: post #20
adrian_b wrote: post #11

Earlier quoted context omitted.

This is a new security feature, which few computers have, so the fact that it does not work obviously has little practical importance. At worst it makes the new computers with this feature only as secure as any old computer. 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 s…

What are you basing “so it must not be used” on? I would think it can’t harm, ever.

Security techniques that have known workarounds cause harm by engendering a false sense of security.

Re: MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips

#32

Post by api »

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?

Re: MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips

#33

Post by Mo3 »

ENOTTY wrote: post #21
ENOTTY wrote: post #8

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 t…

Having grokked the abstract, I feel like can speculate a bit as to what is going on. Take this with a grain of salt; I have no clue what has actually been discovered. 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 ne…

And this can really not be fixed in any way? Not trolling, happy to barely understand this in the first place

Re: MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips

#34

Post by ben7799 »

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.

Re: MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips

#35

Post by _kbh_ »

dreamcompiler wrote: post #31
Someone wrote: post #20

Earlier quoted context omitted.

What are you basing “so it must not be used” on? I would think it can’t harm, ever.

Security techniques that have known workarounds cause harm by engendering a false sense of security.

nearly every security feature in existence has known (situation dependent) work arounds. That does not mean you should turn them off.

Re: MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips

#36

Post by ljhsiung »

Mo3 wrote: post #33
ENOTTY wrote: post #21

Earlier quoted context omitted.

Having grokked the abstract, I feel like can speculate a bit as to what is going on. Take this with a grain of salt; I have no clue what has actually been discovered. 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 ne…

And this can really not be fixed in any way? Not trolling, happy to barely understand this in the first place

Personally, I believe it can be fixed via key rotation (e.g. there are 3 inputs to the PAC algorithm. The pointer, a "modifier", and a "key" e.g. APIAKey_EL1).

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)

Re: MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips

#38

Post by gjsman-1000 »

ben7799 wrote: post #34

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 n…

Also important to mention that PAC is a new ARMv8.2 feature and previous versions of ARM have no PAC system at all. The only ARM chips with PAC are from Apple and AWS Graviton3 - any other chip has no hardware protections against this.

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.

Re: MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips

#39

Post by jprx »

ben7799 wrote: post #34

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 n…

Hi! I think I can clear a few things up here.

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

Post reply on HN