MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips • Hacker News Board

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

#161

Post by avianes » Sat, Jun 11, 2022, 9:53 AM UTC

Findecanor wrote: post #114

Mo3 wrote: post #33

Earlier quoted context omitted.

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

Until it has been fixed in hardware I think it could be mitigated in software a bit, but at a cost. A PAC signature can include also a 64-bit "context" value, which you could make unique per pointer (like a nonce). 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 ker…

I do not understand how you want to mitigate this issue by using the "context" given that the attack demonstration is done with a source code that makes use of the "context". The attack is fully context-agnostic since the "PACMAN gadget" in victim's code is injecting the "context" by itself.

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)

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

#162

Post by fulafel » Sat, Jun 11, 2022, 10:12 AM UTC

adrian_b wrote: post #95

gjsman-1000 wrote: post #38

Earlier quoted context omitted.

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

Besides the Apple CPUs and Graviton 3 (Armv8.4-A), the cores introduced by ARM in 2021 and present in some 2022 smartphones (Cortex-X2, Cortex-A710, Cortex-A510), which implement Armv9.0-A, also support PAC.

The doc in the kernel tree is dated 2017, so it's percolated to products quite slowly: https://www.kernel.org/doc/html/latest/arm64/pointer-authent...

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

#163

Post by jokoon » Sat, Jun 11, 2022, 10:20 AM UTC

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?

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

#164

Post by Fnoord » Sat, Jun 11, 2022, 10:52 AM UTC

azinman2 wrote: post #72

ben7799 wrote: post #54

Earlier quoted context omitted.

Something definitely went wrong here though that more guidance was not provided to the tech journalists. 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.

Welcome to tech journalism.

If the information was given solely to public security experts with blog presence (Matthew Green, Bruce Schneier, and a plethora of others) we could've linked to them and either ignore the 'clickbait middleman' or do most of the work for them allowing them an easier time to write up something half decent.

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

#165

Post by jonathanwallace » Sat, Jun 11, 2022, 10:58 AM UTC

rmbyrro wrote: post #158

bee_rider wrote: post #106

Earlier quoted context omitted.

Based on the article, I think the journalist basically understands the situation (and if they don't, they should investigate further, that's the job). The headline is just intentionally over-dramatic to get clicks. This shouldn't be treated as a good-faith error, more guidance isn't required and wouldn't help.

It's sad that we reached a point where assuming bad faith from public informers is acceptable and, worse, reasonable.

Worth noting that someone else usually writes the headline for the articles, not the journalist / the author of an article.

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

#166

Post by ungamed » Sat, Jun 11, 2022, 11:35 AM UTC

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…

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

^ This is not the case, you can trigger these from userspace in valid syscalls. The same behaviour was in spectre.

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

#167

Post by ungamed » Sat, Jun 11, 2022, 11:36 AM UTC

vinay_ys wrote: post #154

jprx wrote: post #39

Earlier quoted context omitted.

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

Given there are "55,159 potential spots that could be turned into PACMAN Gadgets" do you think it is highly probably this attack is now part of a zero-day kill-chain?

100% chance.

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

#168

Post by ungamed » Sat, Jun 11, 2022, 11:37 AM UTC

MBCook wrote: post #65

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…

Once you can get someone to install your kext aren’t you basically at game over anyway? Or do they have strong limits as well?

This was just to expose the gadget easier, there are other gadgets in kernel that you can abuse too.

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.

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

#169

Post by adrian_b » Sat, Jun 11, 2022, 11:37 AM UTC

astrange wrote: post #77

adrian_b wrote: post #30

Earlier quoted context omitted.

Like you say, it does not do much harm if used. 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 p…

"All programs must be well written" with nothing in the ISA to help you write them properly isn't a good way to do software. PAC helps you reduce bugs because it checksums your pointers.

The most important helping feature of an ISA is to provide an efficient way to compare indices and pointers against limits, so that the poor performance of limits checking will not discourage the compiler writers and the compiler users to always make such checks.

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.

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

#170

Post by temac » Sat, Jun 11, 2022, 11:38 AM UTC

adrian_b wrote: post #159

stevenjgarner wrote: post #85

Earlier quoted context omitted.

For the uninitiated, are such ‘unpatchable’ hardware flaws prevalent and/or debilitating to a greater or lesser degree in other processors (Intel, AMD, Apple AX processors)? Or has Apple "dropped the ball" compared with other chip designers?

All the modern CPUs have a long list of at least several dozens of design defects, most of which are never corrected. 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 manufa…

> then the defect is scheduled for being corrected in a new revision of the CPU

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.