Memory access protections baked into the ARMv8 64-bit specification are vulnerable to being bypassed – and the Arm team has only just mitigated the bug, which would allow an attacker to circumvent its “Privileged Access Never” (PAN) controls in the kernel.
PAN, introduced in 2014, is a meant to prevent privileged access to user data unless explicitly enabled – as a security mechanism against possible software attacks.
A Linux kernel commit message on January 6 this year acknowledges the issue and puts in place a stop-gap measure. But one security researcher, “Siguza” says they originally found the flaw in October 2018 and that PAN “was never an issue to get around”.
(Read Siguza’s detailed write-up here).
Firmware security specialist Eclypsium‘s Yuriy Bulygin told Computer Business Review: “Imagine there’s a bug in the OS kernel code (or a hypervisor) on an ARM device which can cause this code to read from unprivileged memory controlled by a user-mode attacker. The attacker can use this bug to cause the kernel execute arbitrary code.
ARM PAN Bug: –x Memory Doesn’t Trigger PAN
He added: “PAN (Privileged Access Never) is an ARM security feature that prevents kernel-mode (or hypervisor) from accessing memory allocated to user-mode.
“The idea is that even if the kernel is tricked into accessing a page controlled by user-mode attacker, PAN will prevent the access from occurring. This feature is similar to SMAP protection in Intel based CPUs. [Here], due to a bug in the ARM specification, PAN does not prevent access to user-mode pages allocated as execute-only.
Detailing the flaw, Siguza (an “iOS hacker & full-blood shitposter”) notes: “As the commit message above gives away, the bug is plain and simple: –x memory doesn’t trigger PAN… This bug can be exploited on all ARMv8.1+ chips out there where the OS allows the creation of execute-only mappings. Linux used to be such an OS, up until yesterday (rest in RIP). I’ll admit I have no idea about Windows. But I know that iOS was vulnerable not long ago, and to the best of my knowledge, still is at the time of writing.”
Not in a run-at-home fashion, since it's a bug in a mitigation. This can only be exploited when coupled with a kernel pointer dereferencing primitive. I suppose I could hack something up for jailbroken iOS with tfp0, but it'd be ugly and version-specific.
— Siguza (@s1guza) January 9, 2020
The bug comes as yet another reminder of the seemingly endless game of hardware security whack-a-mole: the find comes less than a month after a team of academics demonstrated an attack on Intel’s SGX enclaves (hardware-based isolation and memory encryption) that abuses a previously undocumented software-based interface to attack the CPU and extract cryptographic keys, by “undervolting” the CPU.
(With regard to the flaw in the ARM specification, any attacker would still need to exploit a vulnerability in the kernel from a user-mode exploit code or malicious application, as Bulygin notes to Computer Business Review, adding: “PAN would have complicated the exploitation and an attacker would [have needed to] develop more complex and costly exploits.”) As to a more substantial patch?
Read this: Intel SGX Broken by “Plundervolt” Attack
Siguza notes: “The obvious fix would be to replace that user_r
in the ARMv8 specification with (user_r || perms.xn == '0')
. But that comes a bit late now, so… hooray mitigations. Another obvious fix, as applied to the Linux kernel, is to simply forbid --x
mappings now. I’m pretty sure that wouldn’t bode too well with the WebKit folks and their “bulletproof JIT” however. A third option would be to invalidate ttbr0_el1
on entry to the kernel and only restore it inside of copyio
, but my guess is that this would come with an unacceptable performance hit.”
Apple’s A10 chips (potentially vulnerable) have a proprietary hardware feature that allows them to “strip individual permission bits out of the effective access permission for each bit combination” — this could be used to fix the bug in the company’s chips, Siguza noted. But they warned: “Defensive security folks, and Apple in particular, loooooove mitigations. On iOS, Apple has lately been slapping proprietary mitigations around like there’s no tomorrow. But thing is, mitigations are often delicate creatures, with rather fragile assumptions. Having too many of them in one place can easily make them break one another, as happened here with execute-only memory vs PAN…”
Read this: Citrix Gateway Vulnerability: Exploits Proliferate, as Experts say Gov’t Agencies Exposed