MIT Researchers Uncover 'Unpatchable' Flaw in Apple M1 Chips (techcrunch.com) 56
Apple's M1 chips have an "unpatchable" hardware vulnerability that could allow attackers to break through its last line of security defenses, MIT researchers have discovered. TechCrunch reports: The vulnerability lies in a hardware-level security mechanism utilized in Apple M1 chips called pointer authentication codes, or PAC. This feature makes it much harder for an attacker to inject malicious code into a device's memory and provides a level of defense against buffer overflow exploits, a type of attack that forces memory to spill out to other locations on the chip. Researchers from MIT's Computer Science and Artificial Intelligence Laboratory, however, have created a novel hardware attack, which combines memory corruption and speculative execution attacks to sidestep the security feature. The attack shows that pointer authentication can be defeated without leaving a trace, and as it utilizes a hardware mechanism, no software patch can fix it.
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.
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.
Code Read Only. (Score:5, Interesting)
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).
Re: (Score:3)
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
Re:Code Read Only. (Score:5, Insightful)
That makes it harder to do JIT for JavaScript, etc
Fantastic outcome.
Re: (Score:2)
Re: (Score:2)
Surely, Lisp is so powerful that it can overcome physics, with its infinitude of features and capabilities.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
But Lisp advertizes itself as so powerful that its homoiconicity etc etc should be able to blow compiled programs out of the park without resorting to JIT cheats.
Re: (Score:2)
Lisp advertizes itself as so powerful that its homoiconicity etc etc should be able to blow compiled programs out of the park without resorting to JIT cheats.
Your statement makes no sense. First of all, I've never seen anyone even make that claim. Second, having features X, Y, and Z without compilation is strictly worse than having the same features X, Y, and Z *with* compilation on top of them. BTW what even are "JIT cheats"?
Re: (Score:2)
Re: (Score:3)
Re: (Score:3)
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
Re: (Score:1)
Re:Code Read Only. (Score:5, Informative)
These days, it's known as W^X, or write-xor-execute. That is, a block of memory can be writable, or executable, but not both. You apply this liberally - on the code section (which is typically read only anyways because of the way modern OSes do caching - code text is readonly and pageable so it can be discarded if memory is needed, and then just pulled back from the disk file when eeded). The stack heap and data memory are marked W^X so the processor generates a fault if it tries to execute in those regions.
But that doesn't stop all attacks - and it's so common these days that exploits never generally use a direct buffer overflow to end up running arbitrary code.
In stead, a technique called Return-Oriented-Programming or ROP is used, and what happens is you overflow the stack, but instead of putting executable code there (which can't run as W^X makes it generate a fault), you basically put on a bunch of return addresses so when the processor pops an address off the stack, that address contains a function call to do something the programmer wanted, and the stack is set up with call parameters as needed. So basically the processor returning from a function is treated as stack-indirect jump where the jump address is given by the contents of memory pointed to by the stack pointer.
That's why we have ASLR - return oriented programming requires you to know where the functions you want to call are in memory, so ASLR makes those calls harder to make if you don't know where the functions you want to call are.
Re: (Score:2)
Thanks for that. Wasn't aware of some of what you're saying. I'm rather behind the times :)
read only doesn't stop arbitrary code execution (Score:2)
Another bullshit vulnerability (Score:2)
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.
Re: (Score:3)
If you have the hardware with you and can stick traces on there why bother with the other shit?
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.
Re: (Score:2)
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.
Re: Another bullshit vulnerability (Score:2)
It's annoying that these kinds of vulnerabilities are reported. They are irrelevant to everyone except the NSA.
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
Re: Another bullshit vulnerability (Score:1)
Hardware side channel? (Score:3)
Re: Hardware side channel? (Score:2)
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)
Re: (Score:2)
OK, so it's not a remote attack and you need to set up sensors near the machine to exploit.
Next.
Try reading the last line of the summary. It's a long way down, I know...
Another fine Apple exclusive (Score:1)
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
Re: (Score:3)
Re: (Score:3)
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
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:1)
That is one of the authors recommendations in Part 9. Dont allow spec exec for Pointer authentication. Duh. This could help Qualcomm et al get a better price on arm from the Brits, although an exploit of this seems very unlikely. Also from the paper.
""As part of our reverse engineering effort, we designed PacmanOS, a bare-metal execution environment written entirely in Rust th
Re: (Score:2)
Sources and clarifications (Score:5, Insightful)
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.
Re:Sources and clarifications (Score:4, Interesting)
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.
If Its As Harmless as Apple Says (Score:1)
Not Found
The requested URL
Apache/2.4.7 (Ubuntu) Server at people.csail.mit.edu Port 80
Re: (Score:2)
Apple used the exploit to hack their server and remove it.
Lol. (Score:2)
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.
In a proof of concept, the researchers demonstrated that the attack even works against the kernel â" the software core of a deviceâ(TM)s operating system â" which has âoemassive implications for future security work on all ARM systems with pointer authentication enabled,â says Joseph Ravichandran, a PhD student at MIT CSAIL and co-lead author of the research paper.
âoeIf not mitigated, our attack will affect the majority of mobile devices, and likely even desktop devices in the coming years,â MIT said in the research paper.
Re: (Score:2)
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.
Lemme get this straight (Score:2)
So this "flaw" is that a security mechanism is not perfect? Welcome to the real world.
Re: (Score:2)
Once a hardware mechanism like this one has a known method of breaking it, it's not just imperfect, it's likely completely useless.
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.
First Vulnerabilty with its Own WebSite? (Score:1)
https://pacmanattack.com/ [pacmanattack.com]
Unpatchable but preventable. (Score:2)
CPU: Doctor, I have a critical vulnerability when I do this.
Doctor of CS: Well don't do that.
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!").
Straight from the source: (Score:4, Informative)
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.
Re: (Score:1)
Re: (Score:2)
Thanks. Some of us can still read and understand longer texts after all.
Someone's bonus at the NSA has been cancelled (Score:5, Funny)
Wonderful flaw, carefully implemented, and now spotted. Oh well...
I THINK I'm being paranoid ;)
Well, then, stop writing crappy code... (Score:2)
Buffer overflows are a sign of incompetent coding and incompetent testing. (No, they are _not_ a sign of a bad programmin language, stop pushing that nonsense.) Maybe we should make sure people writing code know what they are doing instead of hiring cheaper and cheaper "coders" that write worse and worse code?
Re: Well, then, stop writing crappy code... (Score:1)
Re: (Score:1)