41–50 of 204 posts
Hi! Joseph (one of the authors) here. You can read more about our attack here: https://pacmanattack.com
You were in touch with them since 2021. Did they manage to fix it for M2? Or is it also valnerable?
Earlier quoted context omitted.
And this can really not be fixed in any way? Not trolling, happy to barely understand this in the first place
Personally, I believe it can be fixed via key rotation (e.g. there are 3 inputs to the PAC algorithm. The pointer, a "modifier", and a "key" e.g. APIAKey_EL1). I would have added that as a potential mitigation in the mitigations section. I think, say, changing the key every so often would be a reasonable task for a kernel to do, especially in the timeframe that this was exploited (about 3 minutes)
Hi! Joseph (one of the authors) here. You can read more about our attack here: https://pacmanattack.com
Is PAC something like the old GCC stackguard canary mechanism done in hardware?
Hi! Joseph (one of the authors) here. You can read more about our attack here: https://pacmanattack.com
Hey Joseph, How does one prove that a hardware exploit is actually 'unpatchable'? Thanks
Seems 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?
This vulnerability it's useless by itself.
Hi! Joseph (one of the authors) here. You can read more about our attack here: https://pacmanattack.com
2 questions.
1) it's relatively known that PAC is brute-forcable given its relatively small key space (16 bits, sometimes 8 if TBI is enabled). How does your attack differ from general brute forces? (My impression is just your leveraging of the BTB/iTLB is a bit more stealthy.) Similarly, in your opinion, would a fix be more ISA-level or you think it's more specific to the M1 (given brute forcing in general is a PtrAuth problem)?
2) you mention in section 8 that this took 3 minutes for a 16b key and tons of syscalls. Wouldn't another proper mitigation be to limit the number of signatures per key? 3 minutes is definitely a long time, and some form of temporal separation may be quite helpful.
OT, but is anyone here also redirected to " " rel="nofollow">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 cert…
Seems 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?
You'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.
Hi! Joseph (one of the authors) here. You can read more about our attack here: https://pacmanattack.com
Hi Joseph! Go Illini! I didn't see you my last semester but I'm glad to see Chris's members doing well in the world. Also always love Mengjia's work. 2 questions. 1) it's relatively known that PAC is brute-forcable given its relatively small key space (16 bits, sometimes 8 if TBI is enabled). How does your attack differ from general brute forces? (My impression is just your leveraging of the BTB/iTLB is a bit more st…
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 this without absolutely destroying performance. Keep in mind the kernel is doing a whole lot more with PAC than just our attack (for example, every function's return address is also signed with PAC) so distinguishing valid uses from a PACMAN attack might be challenging.
I suppose you could track how many speculative PAC exceptions you got, but it's a little late to add that now isn't it? And it could also raise lots of false positives due to type confusion style mechanisms on valid mispredicted paths.