14 ms·
MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips
- donkarma 4y agoSkimmed this really fast, but is this just bypassing PAC by brute-forcing the code with speculative execution?
- macinjosh 4y agoThis is the second hardware security flaw in the M1. Was this known to Apple in time for M2?
- gjsman-1000 4y agoSecond security flaw that is nowhere near as significant as Meltdown/Spectre and their endless derivatives. Still a good showing.
- tcmart14 4y agoJust taking a stab in the dark, I guess we won't know until the M2s are out. On the site by the researchers, they have been in talks with Apple since 2021 about this. To there may be a fix in the M2. However, we won't know for sure until the M2s are out in the public and in the hands of researchers. I don't know what the turn around time is for silicon design on an Engineer's desk to TSMC to being placed in a board on a Mac. It could be that it was too late in 2021 to make a change.
- tikkun 4y agoSounds like it requires physical access to a device, is that right? At least less of a concern than software only, though still not good.
- TazeTSchnitzel 4y agoAs the article puts it, it's a breach in “last line” security defences. Specifically, it's a mitigation that applies when you already have code execution. It's nothing for most people to worry about. PACs are a new mitigation that Intel Macs didn't have, so it's not like it puts the M1 in a worse position than what it replaced.
- adrian_b 4y agoThis is a new security feature, which few computers have, so the fact that it does not work obviously has little practical importance. At worst it makes the new computers with this feature only as secure as any old computer. Nevertheless, the article is very important, because it shows that this supposedly security-improving feature has been implemented in a way that makes it useless (like it has also happened with some Intel security features, e.g. Software Guard Extensions). Everybody must become aware that this "pointer authentication" feature is currently unreliable, so it must not be used, and the designers of future CPUs must take care to not repeat these mistakes.
- Someone 4y agoWhat are you basing “so it must not be used” on? I would think it can’t harm, ever.
- adrian_b 4y agoLike 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 pointer authentication with the jump. I have no idea whether on the Apple CPUs the jumps/returns with authentication have the same speed with the simple jumps/returns. I suppose that the Apple compiler adds automatically the PAC computation and authentication instructions, so using this option does not increase the complexity of the source code. Nevertheless, even if the performance impact of using PAC might not be important, whenever a security feature that does not work is used, there is the danger that there will be some people who do not know that it does not work, so they will believe that exploits are impossible and there is no need to be careful to avoid the possibility that an adversary might be able to modify a pointer, e.g. by crafting a special input to the application. In general all the variants of pointer validation that have been recently introduced in all CPU architectures are just workarounds against the bugs introduced by programmers, because in a well written program there should be no way for an adversary to modify an internal pointer.
- schroeding 4y agoOT, but is anyone here also redirected to "https://guce.advertising.com/collectIdentifiers?sessionId=3_cc-session_<session> 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 certificate is valid, so it also should not be a compromised router or my ISP. Are they A/B testing?
- deleted 4y ago[deleted]
- markovbot 4y agoYeah, I'm getting this too. TechCrunch somehow managed to get even worse. edit: https://spectrum.ieee.org/pacman-hack-can-break-apple-m1s-last-line-of-defense https://spectrum.ieee.org/pacman-hack-can-break-apple-m1s-la... seems to cover the same thing with less spyware
- jeroenhd 4y agoNot 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 here: https://12ft.io/proxy?q=https%3A%2F%2Fweb.archive.org%2Fweb%2F20220610142204%2Fhttps%3A%2F%2Ftechcrunch.com%2F2022%2F06%2F10%2Fapple-m1-unpatchable-flaw%2F https://12ft.io/proxy?q=https%3A%2F%2Fweb.archive.org%2Fweb%... The web archive also seems to be redirected for some reason, though that might as well be intentional. Edit: thinking about it, this might also be an attempt to use first party tracking to bypass third party cookie restrictions. Maybe they're A/B testing a new advertising tool?
- Nextgrid 4y agoA domain "advertising.com" is basically the definition of malware. It's Yahoo/Oauth's spyware domain and as the URL suggests it "collects identifiers" presumably takes a browser fingerprint and sets tracking cookies.
- ENOTTY 4y agoAs someone with a bit of experience in this area, IMO, the Techcrunch article is more confusing than it should be. Here's a link to the actual abstract. The work will be presented at ISCA, which will start on June 18. https://dl.acm.org/doi/10.1145/3470496.3527429 https://dl.acm.org/doi/10.1145/3470496.3527429 Here's a link to MIT's press release. https://www.csail.mit.edu/news/researchers-discover-new-hardware-vulnerability-apple-m1-chip https://www.csail.mit.edu/news/researchers-discover-new-hard... Here's a link to the vulnerability's website, as is tradition now. (Plus the paper) https://pacmanattack.com/ https://pacmanattack.com/
- ENOTTY 4y agoHaving grokked the abstract, I feel like can speculate a bit as to what is going on. Take this with a grain of salt; I have no clue what has actually been discovered. I believe that the researchers have found a way to remove PAC as a barrier to exploitation by disclosing PAC verification results via speculative execution. This is only useful to attackers going after a target that uses PAC, and those attackers will need to have another vulnerability that enables them to hijack control-flow through modifying pointers to code that are located in memory. The attackers can use this new Pacman vulnerability as a crash-free oracle that says whether their forged pointer worked, and once they find a working one, they can use that to hijack control flow. PAC (or Pointer Authentication) is a security feature found in recent iPhones, the Apple Silicon Macs, and the Graviton3. It is intended as a defense against control-flow hijacks. It works by signing pointers found in memory with one of five keys that are known only to the processor. Before the pointer is used, the processor should be instructed to "authenticate" the pointer by checking the pointer's signature using its private keys. To prevent simple reuse of one authenticated pointer used in one place to a pointer used in another place in the program, code can provide a "context" value to be used during the authentication. A great resource for learning about PAC and its usage in the Apple platforms is at [1] (it links to other resources) and if you want to play with a PAC enabled binary, check out [2] [1]: https://googleprojectzero.blogspot.com/2019/02/examining-pointer-authentication-on.html?m=1 https://googleprojectzero.blogspot.com/2019/02/examining-poi... [2]: https://blog.ret2.io/2021/06/16/intro-to-pac-arm64/ https://blog.ret2.io/2021/06/16/intro-to-pac-arm64/ EDIT: The attack works by: 1) Place your guess such that it is used as the pointer input to an authentication instruction 2) Causing a branch misprediction. On the not-taken side of the branch, code needs to perform a pointer authentication and usage of the pointer. On the taken side of the branch, code should not crash. 3) CPU speculatively executes down the not-taken side of the branch (misprediction) and speculatively executes the authentication instruction. 4) If your guess is correct, the authentication instruction will return a valid pointer. If your guess is incorrect, the authentication instruction returns a pointer that, if dereferenced, will cause an exception. 5) CPU speculatively executes a load (in the case of a data pointer) or an instruction fetch (in the case of a code pointer) on the pointer value. 6) If the pointer is valid, the address translation for that pointer will appear in the TLB. If the pointer is not valid, it will not (because of the exception). 7) All of the effects from this mispredicted branch get squashed when the CPU realizes that the branch is not taken. No exception is actually thrown! 8) Measure the TLB entries to determine whether the speculative address translation made it in. If it is present, you know that the guess is correct. 9) Repeat, up to 2^16 times.
- cosmiccatnap 4y agoI wonder at what point we will finally give up on trying to make a stable implementation of speculative execution.
- xxpor 4y agoThe moment someone wants to take the economic hit of a decade+ of performance progress. IOW, not gonna happen. I could see coprocessors becoming more popular though. We already have AES-NI, what if the sensitive keys never ended up in CPU cache because the CPU never had to see them? Specialized HW could not have speculative execution. Granted, that doesn't prevent seeing the plain text of something that's decrypted. It's all about the threat model and what tradeoffs you're willing to make. And that's why Intel et al haven't completely abandoned speculative execution. For the vast vast vast majority of people, the security issues they're much more likely to deal with are straight up getting scammed. Not 0 days, and especially not insane stuff like this. Unless you can turn it into a zero-click iMessage bug (or similar), meh.
- homodeus 4y agoAny reason they aren't using formal verification for this kind of thing? It would seem like a very worthy investment.
- ummonk 4y agoWe basically have zero ability to do formal verification against information leakage through cache timing attacks and the like.
- deleted 4y ago[deleted]
- userbinator 4y agoI wonder at what point we will finally give up on all these "mitigations" which are otherwise pure bloat without the presence of an actual attack, and seem like they don't make things all that much harder even when there is one.
- jprx 4y agoHi! Joseph (one of the authors) here. You can read more about our attack here: https://pacmanattack.com https://pacmanattack.com
- adamsmith143 4y agoHey Joseph, How does one prove that a hardware exploit is actually 'unpatchable'? Thanks
- jprx 4y agoThis 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.
- adamsmith143 4y agoSo there is no possible set of instructions that could block the particular behavior in the exploit?
- jprx 4y agoYou 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.
- fulafel 4y agoThis gets into the turing completeness tarpit. Yes, it's possible to make a vulnerable implementation emulate a chip that is not vulnerable. And maybe even detect when you don't need to emulate and run natively some of the time.
- guardiangod 4y ago
- deleted 4y ago[deleted]
- flerp 4y agoAdlink ahoy
- api 4y agoSeems like if this were successful it would weaken the extra security provided by pointer authentication, at worse weakening it to the level of a CPU without pointer authentication like the x86_64 chips they used to use. So not great but not catastrophic. Or am I missing something?
- rs_rs_rs_rs_rs 4y agoYou'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.
- yosito 4y agoSo not the "last line of defense"?
- Filligree 4y agoIt can reasonably be described as such. The headline implies that previous lines of defense have also been broken, which isn't the case.
- gruturo 4y agoIt 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.
- tester756 4y ago>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
- rs_rs_rs_rs_rs 4y ago
- ben7799 4y agoThe 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 nuts the stories would probably have a different tone. This is interesting theoretically but the amount of access required is pretty high, this is hardly an exploitable zero day. Having read the paper, in a nutshell it requires: - Login to the Mac in question - 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. - Also need an exploitable kernel buffer overflow against Mac OS (they made a custom kext with a buffer overflow) - Run the bufferflow + Pacman Gadget together to do the final elevation If someone can find a way to do this without installing kexts then it becomes way more serious. As is it certainly is a super interesting paper and presents a bunch of work for chip designers.
- gjsman-1000 4y agoAlso 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 terrible, A for effort, was worth a shot, speculative execution breaks everything.
- gjsman-1000 4y agoEdit: Correction, ARMv8.3, not ARMv8.2.
- adrian_b 4y agoBesides 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.
- GeekyBear 4y agoIsn't pointer authentication a feature of the ARM 8.3 instruction set and not an Apple specific thing?
- als0 4y agoYes, it’s defined by ARM. Though the unsafe implementation of speculative execution is obviously by Apple.
- GeekyBear 4y agoIs Apple's implementation the only vulnerable implementation? Prior speculative execution issues applied to more than one vendor's implementation.
- adrian_b 4y agoExcept for the Apple CPUs, only the ARM cores introduced in 2021 implement this. It remains to be seen whether their implementation is better. Until now only few people had access to such recent CPUs, which can be found only in the 2022 models of some smartphones and in the new Graviton 3 servers, so they did not receive much scrutiny.
- BLO716 4y agoThe growing pains of silicon development date back to the Intel line of Pentium FDIV bug issues. Not surprised it occurred, just surprised it took so long to come to fruition. I can only think its the lack of hardware engineers savvy enough to exploit such an issue, since the abstractions from hardware are so far removed from us general populous software developers. Any thoughts on the above?
- stevenjgarner 4y agoFor 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?
- depereo 4y agoYou can look up some other major events such as spectre/meltdown which also used hardware side channels and speculative execution, or rowhammer which affects RAM.
- stevenjgarner 4y agoInteresting! Were the unit testing procedures used in the hardware design and simulation processes themselves flawed? Reading up on these I have not yet been able to elucidate any forensic insight into the original chip design.
- joebob42 4y agoUnit testing isn't really the issue here, spectre / meltdown / rowhammer are pretty fundamental design problems.
- temac 4y agomeltdown / rowhammer are pretty fundamental design problems, spectre is even a pretty fundamental logic problem. It hasn't been comprehensively fixed in HW and probably will never be because it directly contradicts the need for reasonable perf on multicore CPUs (at the intersection between speculative/OOO execution and cache coherency, and both are needed for reasonable perfs). Rowhammer is also hard to comprehensively fix for physics reasons, but hopefully some dedicated mitigations plus ECC are good enough for not ultra-critical applications; some people think more could be done that could practically fix it, but I don't know if they have managed to convince the industry (and get some value from their patents in the process). So of the three, only meltdown could be really fixed by a quick iteration of processor design (and it is also workaround by the OS on old affected models, at a performance cost)
- pizlonator 4y agoSo an attacker who needs to bypass PAC can already sometimes find a nonspeculative PAC bypass, though it’s hard. Assuming they can’t, maybe they can use this, if they can find and weaponize an appropriate gadget in the kernel. Sounds plausible but hard; maybe harder than finding a nonspeculative PAC bypass. Any speculative PAC bypass will also suffer from nondeterminism, so it’s not as practical for an attacker as a nonspeculative bypass. It’s not a given that the speculative PAC gadgets in any kernel are exploitable as effectively as the synthetic kext gadget in the paper. Even if you find a weaponizable PAC gadget in the kernel, and it actually gives you what you want, it’s not clear how reliable it’ll be in practice. So, this is kinda scary but it’s also a bit of theatre. The tech press will have something to write about though.
- saagarjha 4y agoOne “feature” this has is that, assuming no retpoline-like mitigation is constructed to prevent against it, it’s usable for a long time if you can get it to work: at least as long as the gadget remains and conditions remain favorable. Your favorite non-speculative PAC bypass might get patched in the next iOS release and you’re back at square one.
- pizlonator 4y agoAgreed.
- UncleOxidant 4y agoSince the M1 is not being used in servers, how big of a deal is this?
- frankfrankfrank 4y agoConsidering all we have learned over the years, it is not unreasonable to wonder whether this “flaw” isn’t there by design to meet some secret American government vulnerability requirement.
- mike_hock 4y agoThe NSA is holding a portfolio of undiscovered vulnerabilities, whether they've been planted by its operatives or discovered by its researchers. Old ones get discovered independently and patched, new ones get created, all the time. Sending men in black or a top secret letter to a company and demanding a back door has to be the clumsiest possible way to go about introducing a vulnerability. It creates way too many people in the know, anyone could disclose it to researchers like OP who could then claim to have found it independently. It's way more effective to have moles on your payroll.
- josh2600 4y agoThe answer, as always, is that speculative execution is the devil. I’m not convinced you can write a “for” loop safely on a modern processor.
- kurupt213 4y agoProbably an M2 vulnerability too?
- saagarjha 4y agoGiven the disclosure timeline, it’s very likely.
- formvoltron 4y agoummm. Could this flaw be attacked via the web? And Apple cannot fix it?
- pineconewarrior 4y agoNo, not without several other 0-days to exploit. See the other comments here. Essentially, the attacker must have access to another buffer overflow of some sort. This is only a bypass for a specific line of defense, called PAC - a security feature introduced recently in ARM 8.3. By itself, it is not enough to attack a system at all.
- olliej 4y agoMy reading implies you need actual code execution already? As you need to be able lay down the actual auth instruction that you want to force? (Eg nothing so horrific as simply running js) Hahah, ok now I have a much better understanding. It requires an existing path to arbitrary code execution, and a buffer overflow or some such in kernel space. So yes this does defeat one part of the M1 defensive system, which is clearly suboptimal, but the way the article portrays it is absurd.
- userbinator 4y agobut the way the article portrays it is absurd. Spreading paranoia is how the security industry has always operated. It is its incentive, after all.
- olliej 4y agoI know. I think it's this new* habit of giving literally every issue a marketing name is particularly grating, but such is the way of the world :D * A few years old now I guess
- dang 4y agoRelated: https://pacmanattack.com/ https://pacmanattack.com/ https://spectrum.ieee.org/pacman-hack-can-break-apple-m1s-last-line-of-defense https://spectrum.ieee.org/pacman-hack-can-break-apple-m1s-la... (via https://news.ycombinator.com/item?id=31694844 https://news.ycombinator.com/item?id=31694844 and https://news.ycombinator.com/item?id=31694017 https://news.ycombinator.com/item?id=31694017, but we merged the latter hither and the former had no comments)
- calo_star 4y agoI find it so frustrating and disgusting that articles like this don't link to the original research paper/publication.
- serf 4y ago>https://pacmanattack.com https://pacmanattack.com >does PACMAN have a logo? >Yes! great, answering the hard questions. the trend of creating a marketing website for every horrible exploit is so strange. Who are these people selling to, and what? Fear to media outlets is my only guess.
- pjscott 4y agoImagine that you had come up with a delightfully clever way to break pointer authentication using wacky speculative execution side-channel shenanigans. Wouldn't you be proud? Wouldn't you want to give it a cute name and an explanatory web site and a picture of Pac-man in a Venn diagram? I sure would.
- reed1234 4y agoResearchers write papers. They want their papers to be read by many people as they depend on them for their livelihood. Wouldn’t you market yours?
- ayful1 4y agoThis is a great reminder that software and hardware attacks can be combined to construct better exploits. It reminds me of the attacks that used microarchitectural attacks to break ASLR/KASLR.
- olliej 4y agoThe researcher use a kext afaict solely to provide an exploitable gadget - e.g an attacker would need to find one themselves, and finding a kernel bug is not something that gets a journal publication so isn’t relevant to the research. In that case using a kext seems reasonable. The attack itself however seems like it’s fairly close to requiring true arbitrary code execution (the earlier spec. Execution bugs could be unit from “correct” JS).
- jokoon 4y agoI 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?
- neycoda 4y agoMIT has some of the smartest tech people in the world. I wonder if some of smartest malware comes out of MIT somehow?
- collsni 4y agoThe Apple fanboy army is present in this conversation
- deleted 4y ago[deleted]