[deleted]
MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips
191–200 of 204 posts
Re: MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips
#192The 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…
Yeah, the tech news just runs with it because fear sells. This is the “intel backdoor” all over again.
Re: MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips
#193Earlier quoted context omitted.
Welcome to tech journalism.
I can imagine some of the Tech YouTube channel headlines this week: "Apple is DOOMED!" "Turn off your iPhone, Apple's security BUSTED!"
Youtube titles with CAPITALIZED words make me sad. I don't want to click on any video with a title like that, but creators are incentivized to use those titles because they get more views. Some fine videos end up with those titles and I would miss out on some good stuff if I refuse to click on clickbait titles.
Re: MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips
#194Earlier quoted context omitted.
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.
Yep, 100% chance. (Despite the above downvotes, and this is coming from a JavaScript engine researcher).
Re: MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips
#195Earlier quoted context omitted.
Additionally, if can find a way to trick a user into installing a malicious kext, why even bother with PACMAN? You already have arbitrary kernel code execution!
First you need to trick Apple into signing that kext (which is getting more difficult by the day even for legitimate uses), or get the user to disable SIP first.
Didn't many tools require disabling SIP, like Homebrew? Is this no longer true?
Re: MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips
#196Earlier quoted context omitted.
100% chance.
Yep, 100% chance. (Despite the above downvotes, and this is coming from a JavaScript engine researcher).
Yeah, I work on Linux security for a big Red I mean Blue, company. Wrote poc for spectre/meltdown and more, but what do I know. ;)
Re: MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips
#197Earlier 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…
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.
95% of journalism is at this level of understanding for anything non liberal arts that is commonly offered as a 4 year degree, and has been for as long as journalism has existed.
Re: MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips
#198Earlier quoted context omitted.
First you need to trick Apple into signing that kext (which is getting more difficult by the day even for legitimate uses), or get the user to disable SIP first.
Didn't many tools require disabling SIP, like Homebrew? Is this no longer true?
This hasn't been true for at least 2 major macOS releases.
But yes, there was a time when editing even /etc/sudoers required disabling SIP. That time is long gone.
Re: MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips
#199Earlier quoted context omitted.
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…
Speculative exec ruins everything again.
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.
Re: MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips
#200Earlier quoted context omitted.
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…
Would it be possible instead to mitigate this by removing the side-channel: either don't leave any trace in the TLB of the speculative execution, or deny access to the TLB for user mode software?
Unwinding changes to the TLB on every mispredict would have a significant overhead and hurt overall performance. Removing valid data you just cached (speculatively or otherwise) is generally a bad idea.
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.