【GhostWrite#0x01】漏洞利用思路介绍

如果你突然有了任意物理内存地址写的能力，你会做什么？

在 2024 暑期，来自 CISPA 的研究人员发现了国产的 CPU 芯片玄铁 C910 等型号的极高危漏洞，允许攻击者通过 RISC-V Vector 拓展中的错误实现指令实现任意地址物理内存写入。这是工作的官网：https://ghostwriteattack.com/。本篇博客将介绍作者团队使用的漏洞利用方法。

物理内存空间不同于受限的虚拟内存空间，电脑上所有的进程、操作系统内核、虚拟化管理器、设备的内存映射……所有大家能想到的东西都在这里。时光倒流回了 1950s，那个没有虚拟内存的时代。

或许你曾经听说过 Core War：在这个 1984 年的游戏中，双方玩家编写的两个程序会在同一片内存空间中进行角斗，通过覆盖对方的代码等方式尝试“杀死”对方的控制流。我们现在遇到的场景就有些类似于这个游戏。

直接进行物理内存的写入几乎可以无视一切内存安全的保护机制。不论是用户态的 NX、KPTI 还是内核态的 SMEP、SMAP，这些基于页表的检查全都无法发挥作用。留给攻击者唯一的困扰就是地址随机化（KASLR）了，这种保护会在每次内核启动时随机一个加载地址，使得攻击者无法使用硬编码的地址完成攻击。

对于我们今天的主角——RISC-V 架构的玄铁处理器来说，情况则有所不同。直到去年的九月份，RISC-V 架构的 KASLR 支持才被合并进入 Linux 主线的 6.6 版本。

熟悉 Linux 的小伙伴都知道，重视稳定性的发行版常常会绑定某个特定版本的内核，包括 Debian、Ubuntu、CentOS、RHEL 等等。因此，Linux 6.6 以及之后的版本并不会那么快地部署到各个发行版中。（就算新版采用了最新的内核，程序员或许还是喜欢使用老发行版）

比如，目前最新的 Debian 12.6 版本只绑定了 6.1 版本的 Linux 内核；而在 Ubuntu 这边，22.04 LTS 绑定的内核是 5.15 或 5.17 版本，最早使用 6.6 以上内核的是今年发布的 Ubuntu 24.04。总结一下：大部分稳定的发行版都还没有支持 RISC-V 架构的 KASLR！攻击者表示：我从来没有打过如此富裕的仗。

From write to execute

首先介绍普通用户的 root 提权。

Linux 会根据某个进程的 UID 来判断其权限，其中 UID 0 是系统为 root 用户专门保留的 ID。考虑到我们现在能写入内核的任意代码、劫持任意函数，我们可以劫持 getuid() 这一系统调用，将其函数开头覆盖成我们自己的机器码，使它永远返回 0。

sudo、su 这样的 Setuid 程序会通过 getuid() 系统调用来判断用户是否已经是 root，如果是的话（也就是 UID 为零）就不再要求用户进行认证。因此，在劫持了系统调用之后，攻击者直接进行 su 就可以切换成 root 用户，完成攻击。

完整的攻击流程如下：

确定内核加载地址以及函数的偏移；
往 getuid 的物理内存地址处，写入 li a0,0; ret 的机器码；
命令行输入 su，即可切换为 root 用户。

在大部分发行版上，由于 KASLR 不会开启，所以只需要通过本地调试或其他方法拿到 getuid 的地址就行了。至于小部分使用了 6.6 及以上内核版本的发行版，还需要结合进行物理内存的扫描来获取信息，关于物理内存读取的部分，会在后面进行介绍。

如果你想要玩点更加花哨的，想在权限级别更高的 Machine Mode 执行代码，也可以使用类似的攻击手法，直接写入修改 Supervisor 代码。作者以 OpenSBI 这套 Supervisor 实现为例，说明了如何进行 Machine Mode 代码执行：

确定 OpenSBI 的版本号以及加载位置；
修改其中 SBI_EXT_BASE_GET_MVENDORID 这一 SBI ecall 的 handler 代码；
劫持内核调用该 SBI ecall，即可以 machine mode 执行代码。

在基于 C910 的系统上，OpenSBI 的二进制会被加载到固定地址 0x0，不存在随机化的保护，因此上述攻击的第一步并不是一个很难完成的任务。

From write to read

如果攻击者无法确认内核的内存布局（比如内核系统开启了 KASLR 保护），物理内存任意写原语就显得有些力不从心。

作者受到之前利用 rowhammer 漏洞进行提权的启发（这个 DRAM bug 会导致内存中一些比特发生翻转），使用了类似的攻击方法，能基于写原语得到读原语。

页表作为虚拟地址转换的关键数据结构，可以修改它就可以进行任意读写。虽然攻击者不知道自己进程的页表位于物理内存的哪里，但他可以通过不断往内存里映射同一个文件，来让整个物理内存都被自己进程的页表填满。这样以来，攻击者随便写入一个物理地址的内存，就大概率会修改到自己的页表。这也是经典的 NOP Sled 思想。

如果攻击者成功修改到了某个自己进程的页表项，他就可以检测到有一个虚拟地址的映射发生了改变（不再映射到原来的文件）。后续，攻击者只需要继续修改这个页表项，就可以修改对应虚拟地址的映射目标，从而读写任意的物理内存地址。

但注意，能够修改页表相当于只是获取了内核同等级的读写权限，但有一些物理内存区域连内核也无法读取（物理内存保护机制），比如 SMM 所在的内存区域。

下图是我基于自己 patch 过的 qemu，在 ubuntu 22.04 上进行攻击的 PoC。可以看到攻击者的用户态程序成功读出了物理地址 0x80400000 的值。

关于 qemu 的 patch 以及攻击代码，可以见下一篇博客。