利用 ARM 核间调试漏洞获得 SoC 硬件最高权限（下）

前情提要

在 上篇 中，我们给出了大致的漏洞原因和攻击链，在本篇中，我们将给出具体的实验思路和步骤。出于对法律风险的考虑，我们不会给出源码和具体的参数。有兴趣的读者可以根据思路和论文，自行摸索。如有意探讨更多技术细节，请联系我们：zheng.liu@osr-tech.com 。

以下实验步骤在 AArch64 上适用。

LKM 的使用

由于实践环节大量依赖 LKM (Loadable Kernel Module) 作为注入脚本。在此为不熟悉 Linux 内核编程的小伙伴简要介绍一下要点。

LKM 是能够在内核态运行的程序，由 insmod 接口在 root 权限下加载。

如何使用 LKM

如何观察 LKM 运行结果

通过 printk 在内核态输出的结果，只能通过 dmesg 或 cat /var/log/kern.log 查看。

动手

经过上面的准备，刀已磨好，下面开始动手。

查看调试接口的开放情况

翻阅 ARM 架构参考手册（DDI0487），DBGAUTHSTATUS_EL1 寄存器标注了低八位寄存器的意义。

在论文 [1] 中，作者详细描述了这四种调试方式的差异，简单来说，如果低八位的值为 0xFF...

读取该寄存器的方法，可以通过 inline assembly 的方式，直接读这个寄存器的值就好了。

翻找调试寄存器基址

如果 DBGAUTHSTATUS_EL1 的值是 0xFF，下一步就是找到 Externel Debug Registers 和 Cross Trigger Interface registers 正式进行 Nailgun 实验。

从软件上看，EDR 和 CTI 是两组地址编码为 0x1000 大小的寄存器。访问该寄存器组中的独立寄存器，是通过基址 + 偏移的方式。偏移在 ARM 手册中都给出了准确值，困难的是这两个模块并不属于开放给第三方的外设，因此在公开的 SoC 手册里几乎不可能找到准确的寄存器基址（极大概率在 SoC 手册上被划入了 reserved 或语焉不详）。对此，只能来硬的。

饱和式搜索——穷举！

幸运的是，在 CTIDEVID 寄存器中，对于 Cortex-A53 而言，它低几位值是固定的，为 0xnn040800。因此在一个合理的地址范围内，搜索一个以 0xFC8 结尾，0x1000 为间隔的地址，其值低 24 位为 0x040800 的匹配并不算太难。需要注意的是，ARM 手册中的这个地址是物理地址，在 LKM 中进行编码的时候需要通过 ioremap() 进行地址映射。

如果幸运女神真的瞄了你一眼，获得了匹配，请进入下一步。

如果在扫描的过程中频繁遇到内核崩溃，系统假死，芯片烫烫烫得要命... 我们可以通过一个工具缩小范围。

ARM 的工作小组提供了一个工具，帮助通过查看 ROM Table 中特定位置的值，协助确定搜索的范围。他们的工具开源在这里（https://github.com/ARM-software/CSAL） 。使用方法请自行阅读。

通常来说 SoC 中每一个核心对应一对 EDR 和 CTI，其用来调试该核心，所以八核 A53 会找到八组对应寄存器，不过也有例外……（坑可真多）

让代码在 Core 1 上运行

由于我们要停住 SoC 的一个核心，将代码在另一个核心上执行，因此需要告诉系统，指定代码运行的核心编号。

smp_call_function_single(1, payload_func, arg_struct, 1);

以上从 Nailgun 论文里抠出的代码，意思是：将 payload_func 在 Core 1 上执行，其中 payload_func 有一个参数叫 arg_struct。所以，把需要实现的功能写到 payload_func，把需要的地址放到 arg_struct 以指针传入，运行这条函数，不出意外的话可以得到正确执行。

通过核间调试访问 Core 0

如果以上步骤都成功完成，那么按照论文作者的 PoC [2] 就可以直接通过调试接口操作 Core 0 核心进行读写，读写方式就是最基础的 value = ioread(addr) 和 iowrite(addr, value) 。步骤如下：

用一个不严谨的流程图来表示，就是 Core 1 通过 CTI 和 EDR 来操作 Core 0 的运行。

在 Core 0 上执行代码

通过调试寄存器让 Core 0 执行代码，其根本方式就是将待执行的指令翻译成机器码，将机器码写到 EDITR 寄存器（32位），通过查询 EDSCR 标志位，得知指令的执行情况。遇到权限错误无法执行的指令，EDSCR 会在特定标志位给出指示。原作者的代码如下：

static void execute_ins_via_itr(void __iomem *debug, uint32_t ins) {
    uint32_t reg;
    // clear previous errors
    iowrite32(CSE, debug + EDRCR_OFFSET);

    // Write instruction to EDITR register to execute it
    iowrite32(ins, debug + EDITR_OFFSET);

    // Wait until the execution is finished
    reg = ioread32(debug + EDSCR_OFFSET);
    while ((reg & ITE) != ITE) {
        reg = ioread32(debug + EDSCR_OFFSET);
    }

    if ((reg & ERR) == ERR) {
        printk(KERN_ERR "%s failed! instruction: 0x%08x EDSCR: 0x%08x\n",
            __func__, ins, reg);  
    }
}

最终效果，是在内核不崩溃的情况下读出 SCR_EL3 寄存器的值。

因为 ARM 手册写着，只有当前状态处于 EL3 时，才允许读取该寄存器。

内核崩溃的处置

由于 Nailgun Attack 是涉及未知硬件实现的软件代码，因此在实验当中一定会频繁遇到内核崩溃的情况。在此有几条建议，帮助大家趟坑。

总结

Nailgun Attack 是一个可能很早以前就存在，却没有被大家认识的硬件实现漏洞。这种漏洞可能缘于 ARM、SoC 设计方、OEM 产品方等多方在产品设计时因考虑问题的角度不同，因而对调试功能的态度和能力不同所导致。一个本应是方便开发和调试的功能，最终成为一个终端产品上广泛存在的漏洞，如何防止未来出现类似多方安全性问题，值得大家思考。安全，作为一个贯穿整个产业链的的概念，在产品的设计、生产、销售、使用和回收等各个环节都需要有所准备。

最后，围绕 Nailgun Attack，我们开发了一个自动化的检测工具，将针对 Nailgun 漏洞对目标设备进行远程扫描，快速得知设备被漏洞影响的程度。相关信息我们将在近期公布，欢迎垂询。

[1] Understanding the Security of ARM Debugging Features http://www.cs.wayne.edu/fengwei/paper/nailgun-sp19.pdf

[2] https://github.com/ningzhenyu/nailgun/blob/master/PoC/Read_SCR/