MIT Researchers Uncover 'Unpatchable' Flaw in Apple M1 Chips - Slashdot
source link: https://apple.slashdot.org/story/22/06/11/0250238/mit-researchers-uncover-unpatchable-flaw-in-apple-m1-chips
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
MIT Researchers Uncover 'Unpatchable' Flaw in Apple M1 Chips
Become a fan of Slashdot on Facebook
binspamdupenotthebestofftopicslownewsdaystalestupid freshfunnyinsightfulinterestingmaybe offtopicflamebaittrollredundantoverrated insightfulinterestinginformativefunnyunderrated descriptive typodupeerror
The attack, appropriately called "Pacman," works by "guessing" a pointer authentication code (PAC), a cryptographic signature that confirms that an app hasn't been maliciously altered. This is done using speculative execution -- a technique used by modern computer processors to speed up performance by speculatively guessing various lines of computation -- to leak PAC verification results, while a hardware side-channel reveals whether or not the guess was correct. What's more, since there are only so many possible values for the PAC, the researchers found that it's possible to try them all to find the right one.
-
›
This is something that IBM Mainframes have had since they existed, pretty much.
A "Code" block is read only. Nothing can write to that except the initial loader, after which it is set to read only in a hardware layer.
You can do stack overflows all you want, but you're never going to be able to modify that code from within a program (or another program for that matter, since it's invisible from that other program to begin with).
-
That makes it harder to do JIT for JavaScript, etc. You can design a processor to make it more secure, sometimes you must make a decision between performance and security. For Apple many of these decisions were already made by ARM and can't be altered without creating incompatibilities and agreement violations of the licensed architecture.
A slow and steady processor that eliminates many common optimizations could be made immune to all known side channel attacks. The lack of prediction may prevent the cache
-
That makes it harder to do JIT for JavaScript, etc
Fantastic outcome.
-
Horrible outcome. I like my interactive Lisp environments, thank you very much.
-
-
-
That is a 360 green card (programmer's architectural model) perspective that is too narrow to tell modern truth. Many of these recent attacks target the memory system (DRAM refresh, cache, multi-core cache consistency). Even the limited pipelining in 360/91 would give behaviors outside the common green card understanding, with imprecise exceptions.
-
But that's kind of the point, isn't it? Modern CPU architecture are pretty much designed for performance over anything else, and security seems to be very low on the priority list.
Whereas the 360/370/390 series were very much designed to be as secure and segmented as possible.
My experience is mostly in assembly on those systems, and the finegrained control you could exert over things (primarily wrote RACF related stuff, so my experience is very coloured by that, admittedly), was always something that made m
-
-
This is something that IBM Mainframes have had since they existed, pretty much.
A "Code" block is read only. Nothing can write to that except the initial loader, after which it is set to read only in a hardware layer.
You can do stack overflows all you want, but you're never going to be able to modify that code from within a program (or another program for that matter, since it's invisible from that other program to begin with).
These days, it's known as W^X, or write-xor-execute. That is, a block of memory ca
-
If I know the read only code and I can hack the stack I can search the read only code for the instructions that I want that are just before a return instruction. I then "compile" my code so that my program is a bunch of stack variables and return pointers.
-
-
If you have the hardware with you and can stick traces on there why bother with the other shit?
And that's one pointer. There are millions of pointers active.
It's annoying that these kinds of vulnerabilities are reported. They are irrelevant to everyone except the NSA.
-
It's almost as if you missed the line where it says "since there are only so many possible values for the PAC, the researchers found that it's possible to try them all to find the right one."
A PAC might be only 40 bits and it's no big deal to brute force that these days.
-
-
Reminds me of when I got my first Acorn Archimedes back in the 1980s.
One of the first things I dad was write a program to see of the random() function took exactly 2^33-1 iterations to repeat the sequence. (it did!)
It took a couple of hours to run.
The same program would probably run in a few seconds these days.
-
-
-
Or, if you look at the bright side, they're publicizing a method that might enable you to hack your computer's hardware in a way that might allow you to defeat annoying DRM used against you.
If an exploit requires deliberate, permanent hardware modification, it's unlikely to be useful against your own personal interests unless you're someone who has state-sponsored espionage agencies teaming up against you (in which case you're probably fucked one way or another, anyway, unless you're the President of the US
-
-
OK, so it's not a remote attack and you need to set up sensors near the machine to exploit.
Next.
-
Doesn't necessarily mean you have to have Hardware. Side Channel exploits in Hardware can be discovered by software.
Sounds like Pac leaks via some other hardware mechanism (power usage, RFI, timing hiccups)
-
Try reading the last line of the summary. It's a long way down, I know...
-
-
Last month we discussed an unpatchable, inherent flaw in Apple's processors [slashdot.org] which "leaks data at rest [prefetchers.info]". (Which, I might add, would once have been linked as a related story... in the pre-B!zX days that is.) Now we've got yet another failure. Apple fans have gushed and gushed about the performance of these chips but they're getting their comeuppance now in exactly the same way as Intel's followers, where the performance advantage goes away when security is taken into account.
It will be interesting to see if A
-
You are making an assumption that they need to patch the issue.
-
I see you didn't read the second paragraph of my comment, probably because you were triggered by the first one. You really need to segregate these brands from your identity. It's not healthy to identify yourself with a publicly traded corporation that could not possibly give one fuck about you, because corporations don't have hearts, minds, souls... or consciences.
Apple is going to have to mitigate at least the Augury flaw discovered in May, because it has been demonstrated that it can be practically exploi
-
This âoeattackâ will work on any ARM v8.3 CPU. And it does not actually attack anything, it defeats a security measure, rendering v8.3 as insecure as v8.2 and earlier, which is not the end of the world. You still need an underlying exploit.
For someone professing to eschew brand identification, you sure focused on Apple a lot for what is an ARM-wide design flaw.
-
More specifically, any ARM v8.3 CPU running an arm64e binary that actually uses the feature, which is limited pretty much (as far as I've seen) to just Apple's binaries.
-
-
-
-
I bought into the ecosystem (I own 2 M1* machines, now) knowing full well the sidechannel guys were going to have a hayday with them. I'm really ok with that.
It's hubris or koolaid intoxication to think that any processor is immune to such things.
The previous one worse than this.
This just means arm64e binaries may as well be arm64, which is fine.
As for mitigation? No way in hell.
If the PAC is broken, arm64e mach type is pointless until it's fixed in a future silicon. Linux doesn't really apply much h -
Apparently not Apple Exclusive: https://hardware.slashdot.org/... [slashdot.org]
-
-
The original authors have documented their attack in this website [pacmanattack.com], and it has been accepted for ISCA'22 [iscaconf.org]. It will be presented in 10 days, and the actual paper is already available here [pacmanattack.com].
The work does not attack apple M1; the work attacks a security mechanism in ARM, introduced in ARMv8.3. They have employed the Apple M1 processor, which employs ARMv8, but it is very likely that many other ARMv8-based processors will have the same limitation.
The attack does not allow you to compromise a system by itself. ARM Pointer Authenticator Codes is a security mechanism that prevents exploiting some memory corruption vulnerabilities. With this new attack, it is again possible to exploit code that has vulnerabilities. It is the memory corruption vulnerability in the code the one that will allow attackers to compromise the system, PAC was an additional protection to prevent it.
-
After reading other comments, some additional clarifications:
First, this does not seem to be a "hardware attack". It is a software attack; it employs a micro-architectural side-channel attack to exploit a hardware mechanism (PAC). To perform this attack, it is required to have access to high-resolution timers. Second, as it is not a hardware attack, there is no need to have physical access to the system of install physical sensors of any type.
-
-
Then why did MIT remove the paper - or was it flawed?
Not Found
The requested URL/weontaek/pubs/PACMAN_ISCA22.pdf was not found on this server.Apache/2.4.7 (Ubuntu) Server at people.csail.mit.edu Port 80
-
Apple used the exploit to hack their server and remove it.
-
-
I submitted this exact article with this exact summary text yesterday afternoon.
The article goes on to say that these vulnerabilities are likely present in *all* ARM architectures.
-
This vulnerability is a flaw in a security measure which is intended to protect against a known vulnerability. So while the underlying vulnerability is likely present in all ARM architectures, Apple's failure to craft a successful mitigation is what's at issue here.
-
-
So this "flaw" is that a security mechanism is not perfect? Welcome to the real world.
-
-
100% correct. This means that arm64e is pointless, and you may as well compile targeting arm64.
Which is fine, because everyone besides Apple already does that.
-
-
-
Seems this PACMAN has their own advertising staff, jeez louise. This is their link from BleepingComputer.
https://pacmanattack.com/ [pacmanattack.com] -
A twist on an old joke but it's actually precisely how you address non-patchable hardware issues like this. Spectre vulnerabilities were addressed by modifying OS kernels and compilers and redeploying everything. I suspect Apple has been working on a similar approach to prevent this from being possible while publicly downplaying the fact that this is a full compromise ("If only run authorized software, there is no problem!").
-
Original MIT article: https://news.mit.edu/2022/rese... [mit.edu]
The paper: https://pacmanattack.com/paper... [pacmanattack.com]
Site about vuln: https://pacmanattack.com/ [pacmanattack.com]Seriously, TechCrunch is crap compared to these.
-
thanks for the link to the paper. i didnt get past their glitzy frontpage -
-
-
Wonderful flaw, carefully implemented, and now spotted. Oh well...
I THINK I'm being paranoid;)
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK