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

51–60 of 204 posts

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

#51

Post by [deleted] »

jeroenhd wrote: post #9
schroeding wrote: post #5

OT, but is anyone here also redirected to " " rel="nofollow">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 cert…

Not on my side, but it wouldn't be the first time some third party advertising server would be serving malware. Malvertising will restrict itself to only some visitors to make sure it's not detected and blocked too quickly. 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 he…

[deleted]

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

#52

Post by Filligree »

yosito wrote: post #48
rs_rs_rs_rs_rs wrote: post #45

Earlier quoted context omitted.

You're right, that's exactly what this is. Just a way to defeat a defense in depth measure. This vulnerability it's useless by itself.

So not the "last line of defense"?

It can reasonably be described as such. The headline implies that previous lines of defense have also been broken, which isn't the case.

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

#53

Post by gruturo »

yosito wrote: post #48
rs_rs_rs_rs_rs wrote: post #45

Earlier quoted context omitted.

You're right, that's exactly what this is. Just a way to defeat a defense in depth measure. This vulnerability it's useless by itself.

So not the "last line of defense"?

It is. It's just that compromising the last line of defense, without compromising the ones which come before it, is not the end of the world.

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.

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

#54

Post by ben7799 »

jprx wrote: post #39
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 us…

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.

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

#56

Post by tester756 »

gruturo wrote: post #53
yosito wrote: post #48

Earlier quoted context omitted.

So not the "last line of defense"?

It is. It's just that compromising the last line of defense, without compromising the ones which come before it, is not the end of the world. 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.

>is not the end of the world.

today, how many years it took the theory to be applied in "real world" with other cpu vulns

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

#57

Post by MertsA »

bogwog wrote: post #22
guardiangod wrote: post #15

Earlier quoted context omitted.

(Will read the paper later) How lawyer-y do you think Bandai Namco will be?

They probably won't care about this, although I do find it weird when researchers make a whole website with custom domain just to publish something like this. Personally, it comes off as less trustworthy since it enters the same realm of bullshit as those market manipulation attacks on AMD a few years back[1] Not saying that's what this is (I'm sure these are legitimate findings), but this tactic raises some red flag…

Yeah I hate this trend of naming vulnerabilities and pandering to the tech press. The CTS Labs FUD was just beyond the pale. Most tech journalism just ate up those claims that were clearly B.S. and not even self consistent. They were claiming it was impossible for AMD to patch with firmware or microcode but in the same sentence claiming an attacker could use it to create a rootkit that couldn't be removed. Nobody bothered taking two seconds to think critically about what they were publishing to realize they were claiming that it was, in essence, somehow possible for an attacker to "pull up the ladder behind them" but not for AMD.

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.

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

#58

Post by adamsmith143 »

jprx wrote: post #44
adamsmith143 wrote: post #40

Earlier quoted context omitted.

Hey Joseph, How does one prove that a hardware exploit is actually 'unpatchable'? Thanks

This is a great question! What this means is that a software patch cannot fix the speculative execution behavior that causes the PACMAN issue since it is built directly into how the hardware operates.

So there is no possible set of instructions that could block the particular behavior in the exploit?

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

#59

Post by ljhsiung »

jprx wrote: post #49
ljhsiung wrote: post #46

Earlier quoted context omitted.

Hi Joseph! Go Illini! I didn't see you my last semester but I'm glad to see Chris's members doing well in the world. Also always love Mengjia's work. 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 st…

ILL-INI!!! 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 thi…

Thanks for the quick answers.

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.

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

#60

Post by jprx »

adamsmith143 wrote: post #58
jprx wrote: post #44

Earlier quoted context omitted.

This is a great question! What this means is that a software patch cannot fix the speculative execution behavior that causes the PACMAN issue since it is built directly into how the hardware operates.

So there is no possible set of instructions that could block the particular behavior in the exploit?

You could maybe do it with lots of fences or just a ridiculous chain of NOPs after each branch such that the ROB is cleared before you have time to try to load a pointer speculatively.

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.

Post reply on HN