8 ms·
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
by ben7799 4y ago
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 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.
- fulafel 4y agoThe doc in the kernel tree is dated 2017, so it's percolated to products quite slowly: https://www.kernel.org/doc/html/latest/arm64/pointer-authentication.html https://www.kernel.org/doc/html/latest/arm64/pointer-authent...
- shp0ngle 4y agoAh thanks, this finally makes sense in context
- jprx 4y agoHi! 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 used in the attack does not require a kext (we just use the kext for doing reverse engineering) but the attack itself never uses the kext timer. All of the attack logic lives in userspace. Provided the attacker finds a suitable PACMAN Gadget in the kernel (and the requisite memory corruption bug), they can conduct our entire attack from userspace with our multithread timer. You are correct that the PACMAN Gadget we demonstrate in the paper does live in a kext we created, however, we believe PACMAN Gadgets are readily available for a determined attacker (our static analysis tool found 55,159 potential spots that could be turned into PACMAN Gadgets inside the 12.2.1 kernel). Our paper is available at our website: https://pacmanattack.com/paper.pdf https://pacmanattack.com/paper.pdf
- ben7799 4y agoSomething 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.
- azinman2 4y agoWelcome to tech journalism.
- sirspacey 4y agoWelcome to journalism.
- rTX5CMRXIfFG 4y ago
- MBCook 4y agoOnce you can get someone to install your kext aren’t you basically at game over anyway? Or do they have strong limits as well?
- ungamed 4y agoThis was just to expose the gadget easier, there are other gadgets in kernel that you can abuse too. The full fix will require a complete recompile of the full kernel/toolchain, if they can do any kind of microcode update (I have not checked) that allows for mitigation.
- throwaway290 4y agoInstalling a kext is a password prompt away, I believe, so all that's needed technically seems to be "install something not reviewed by Apple, fill in a genuine OS password prompt when asked, and run it" which strikes me as a very common scenario.
- bhj 4y agoEnabling 3rd-party extensions is much more involved on AS Macs: https://support.apple.com/guide/mac-help/change-security-settings-startup-disk-a-mac-mchl768f7291/mac https://support.apple.com/guide/mac-help/change-security-set... Then the extension needs to be allowed in System Preferences > Security (this step has been required on Intel Macs too)
- jprx 4y agoAdditionally, 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!
- throwaway290 4y agoPerhaps the kext with the overflow may not necessarily look malicious? It can serve as an actually useful kext and pass review.
- shp0ngle 4y agoyeah but if you can trick the user to do that, you can already trick him to do more
- aenis 4y agoThese days all kexts look malicious.
- ntauthority 4y agoYeah. The bundled ones in the main OS image are the worst. Who the hell knows what nefarious acts lie behind IOPCIFamily.kext?! /s, though not entirely, moving more stuff to unprivileged contexts would be nice
- woliveirajr 4y ago> "PACMAN is an exploitation technique- on its own it cannot compromise your system. While the hardware mechanisms used by PACMAN cannot be patched with software features, memory corruption bugs can be." reading the "official" site of the Researchers gives more clues than the headline of the article.
- metamuas 4y agoI downloaded Brave after googling it and got a .pkg instead of a .dmg because someone wanted to hack my new laptop, and didn't want to risk a hack that leveraged an exploit only nation states know about. They are sMArt. Like me! I still installed it because I am gullible and lazy.
- beckman466 4y ago> Login to the Mac in question right, ok? as Snowden thankfully heroically warned us, the NSA already has root-level access to most devices. “ Remember the Spectre vulnerability. Now we have more than 7 variants of Spectre. No one guarantees that new, more destructive versions of this vulnerability will not be discovered in the future.” > If someone can find a way to do this without installing kexts then it becomes way more serious. right, yeah, you’re onto the right trail now.
- WuxiFingerHold 4y ago> - Login to the Mac in question Really? Usually malicious stuff is installed by the user themselves being unaware of it.
- fulafel 4y agoFrom the home page: " For our demo, we add our own bug to the kernel using a kext. In a real world attack, you would just find an existing kernel bug." This is attacking a memory safety exploitation mitigation tech, there needs to be a memory safety bug. Otherwise there's no need for PAC in the first place.
- ungamed 4y ago> - 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. ^ This is not the case, you can trigger these from userspace in valid syscalls. The same behaviour was in spectre.
- Aleksdev 4y agoYeah, the tech news just runs with it because fear sells. This is the “intel backdoor” all over again.