Once thought
that having root
meant having the world
Until I encountered it
only then did I realize
there is actually a brighter future (big mistake)
Introduction
Gaining root access to an operating system is generally considered the endpoint of penetration attacks. However, with the support of security solutions based on TEE (Trusted Execution Environment), even root access often proves ineffective in obtaining sensitive information. The reason is that within ARM processor architectures, there exists a hardware-enforced privilege level (Privilege Level or Exception Level) that is higher than root access. At the highest privilege level, it is even possible to modify critical parameters such as virtual-to-physical address mappings at runtime.
In May 2019, NING Zhenyu and ZHANG Fengwei from Wayne State University disclosed a method to exploit the inter-core debugging capabilities of ARM to escalate privileges from the normal world EL1 to EL3, thereby bypassing the privilege isolation mechanisms on ARM processors to access secure world data [1]. They named this attack method the Nailgun Attack.
In July of the same year, Brandon Azad from the top security team Project Zero discovered that a similar inter-core debugging mechanism was not disabled on the A11 chip used in the iPhone X, allowing attackers to perform kernel debugging and potentially obtain more information from SecureROM [2]. Brandon reported this to Apple, but it was not acknowledged as a security risk due to the lack of apparent harm [3].
We have carefully studied the formation causes and attack paths of the Nailgun Attack and believe that this attack poses a security threat in certain application scenarios. Here, we will share the principles of this attack and provide practical attack steps.
Prerequisite Knowledge
To better understand the mechanisms and dangers of the Nailgun Attack, we will introduce some basic concepts used in this attack. To simplify the description, we make the following assumptions before implementing the Nailgun Attack:
-
The target device is an ARMv8-A AArch64 system.
-
The attacker has root access.
Overview of the Linux Kernel
The Nailgun Attack is based on Linux and can be extended to Linux-like systems such as Android and iOS, which are also the main operating platforms for ARMv8-A.
We will not elaborate on operating system principles, but simply put:
-
The kernel is the program responsible for important operations within the operating system and has high privileges.
The kernel acts as an intermediary layer between hardware and application software, helping applications orderly access hardware resources.
-
User programs running under Linux are considered application programs and operate in user mode, without direct access to hardware.
-
If a program needs to directly access hardware resources, it must enter a high-privilege state known as kernel mode.
-
Kernel mode execution requires root access.
In the Nailgun Attack, we need to write code that directly accesses hardware registers, which means running in the kernel. Linux provides a functional interface for this, called Loadable Kernel Module. After compiling the program into a format acceptable to LKM, it can be loaded into kernel mode using the <span>insmod</span> command.
ARM Hardware Privileges
In hardware, ARM has designed multiple levels of software execution privileges for ARMv8 AArch64 systems, known as Exception Levels (EL). Each EL level corresponds to different software functionalities; simply put, the higher the hardware EL level during software execution, the greater the privileges of the software code. The code at the highest level, EL3, is often the BootROM code that is verified and not allowed to be modified.
Referring to a classic structure diagram of ARM TEE [4], for example, the application at EL0 level is a normal user-mode program. EL1 level is for kernel-mode programs with root privileges, EL2 level is typically for programs that build virtualization instances on servers, while EL3 level is for the basic bootloader in BootROM, responsible for the startup process and handling critical exceptions, commonly referred to as ARM Trusted Firmware (ATF) in ARM architecture.
Once the processor is in EL3 state, it means that it can modify any data, code, and registers below this privilege. Therefore, the interfaces and channels for entering EL3 state are strictly controlled. Normally, to escalate from EL1 to EL3, one must enter through the <span>smc</span> instruction to trigger a system interrupt, and the interrupt handler is fixed at compile time in BootROM and cannot be modified at runtime.
ARM Inter-Core Debugging
In the ARMv8-A processor family, almost all designs are ultimately produced in a multi-core manner. From A53/A55/A57 to A72/A73/A75, the “multi-core A53 architecture” and “big.LITTLE” are the most well-known product architecture names in recent years. In the initial design of ARMv8-A processors, in addition to being able to connect hardware debuggers via the JTAG interface (as shown below [5]), multi-core products can also utilize inter-core debugging, allowing one core to debug programs running on another core through the debugging module within the ARM core. This not only eliminates the hassle of purchasing and connecting hardware debuggers but also achieves the goal of “sitting at home while the machine is debugging in the sky.”
To achieve such a god-like experience, ARM has designed a debugging circuit that is included by default in every ARMv8-A core (including some ARMv7-A cores). Flipping through the over six thousand pages of the ARMv8 Architecture Reference Manual [6], one can find descriptions of two sets of registers in ‘External Debug Register Descriptions’, namely External Debug Registers (EDR) and Cross-Trigger Interface registers (CTI), which are used to control the debugging state and operations of ARM cores. ARM has given them and their counterparts a resounding name, CoreSight(R). Other functional registers in the CoreSight component will not be elaborated here. For the Nailgun Attack, these two sets of registers can almost meet all attack requirements.
If the processor core Core 0 is in debugging mode, how is the exception level determined during its execution?
The answer is: it is not determined. That is, the code execution is not restricted by the hardware EL level.
Vulnerability
Since the code executed by Core 0 in debugging mode is not restricted by the current exception level, Core 0 can actually execute code under any exception level. By combining the inter-core debugging functionality, we can send high-privilege execution code from Core 1 to Core 0 through the debugging interface, allowing Core 0 to execute operations that can only be performed by EL3 programs.
Attack Chain
- Find the address of Core 0’s debugging registers;
- Write code to access Core 0’s debugging registers. In the code, read and write data under EL3 privileges;
- Compile the code into LKM under root privileges and inject it into the kernel;
- Silently complete execution in the kernel, and return data through
<span>printk</span>or other means (even as a driver returning to user mode);
Impact Scope
All ARMv8-A multi-core processor products may be affected.
Since inter-core debugging via CoreSight is a hardware feature, only chip vendors can fundamentally resolve the issue through hardware revisions.
Preventing root privileges or LKM loading functionality in the attack chain can also mitigate the impact.
Postscript
Although the attack chain consists of only four steps, the first step of finding the debugging register is quite intricate… 😛
Since SoC manufacturers do not disclose all register addresses, even if the offset addresses of EDR or CTI can be obtained from ARM’s public manuals, their base address remains a secret. Some vendor SoC development board materials may provide a glimpse, but accurate register base addresses require deeper research into the ARM architecture.
To know what happens next, stay tuned for the next installment.
References
[1] https://compass.cs.wayne.edu/nailgun/
[2] https://googleprojectzero.blogspot.com/2019/10/ktrw-journey-to-build-debuggable-iphone.html
[3] https://bugs.chromium.org/p/project-zero/issues/detail?id=1900
[4] https://developer.arm.com/docs/100935/0100/switching-betwen-the-normal-and-secure-worlds
[5] https://www.suse.com/c/debugging-raspberry-pi-3-with-jtag/
[6] DDI0487b_a_armv8_arm.pdf (the latest version has evolved to DDI0487f)
Everything is interconnected, security empowers Scan to follow the latest updates
About Niu Chuang Xin An OSR
Shenzhen Niu Chuang Xin An Technology Development Co., Ltd. (Open Security Research Inc., OSR), established in 2014, is headquartered in Shenzhen with a research and development center in Beijing. It is a national high-tech enterprise focused on security attack and defense technology, providing customers with high-security IP and attack testing services.
Niu Chuang Xin An is committed to automating, intelligentizing, productizing, and visualizing financial-grade security attack and defense technologies with leading hardware security attack and defense technology and innovative hardware security methodologies, forming an open methodology to empower security across various vertical industries in the era of the Internet of Everything, and aims to become a leader in security technology in the new era.
OSR’s products and services cover hardware security testing equipment, security algorithm acceleration, hardware security solutions, and security consulting services, with typical clients and partners including State Grid, Southern Power Grid, Tair Lab, Goodix, Tsinghua Unigroup, Yuntian Lifeng, C-Sky, Synopsys, and others.