CVE-2020-0022

非常感谢 Insinuator 的精彩博文和代码！

结果

Insinuator 帖子中提到的所有步骤都已完成，而且还不止于此。要把这些步骤写进 README.md 文件实在太多了，所以请随意查看上面提到的 Insinuator 的帖子。

该漏洞利用已完全完成，达到了以下程度：

1. 攻击者控制的足够大的内存区域的地址被泄漏
2. 程序计数器被修改为指向自定义地址
3. 自动进行重试，显著降低了失败的概率
4. 代码在断开连接时间和内存搜索速度方面进行了优化，已达到进一步优化会危及漏洞利用稳定性的程度

差异与改进

此漏洞利用与 Insinuator 的实现有以下不同：

1. 使用 C 语言而非 Python 编写（因为我热爱 C）
2. 以模块化方式编写，每个模块负责一个特定任务
3. 在运行 Android 9 (PQ3A.190801.002, Security Patch Level 2019-08-01) 的 Pixel 3 XL 上进行了测试，因为我手头正好有这台设备
4. 泄漏的是 libandroid_runtime.so 中的地址，而非 libicuuc.so，因为前者在这台手机/目标上效果更好
5. 实现了两个示例 JOP 链，一个直接调用 execv，另一个先调用 fork 再调用 execv
6. 附带了自定义 Ghidra 脚本，用于处理 libandroid_runtime.so 文件并提取函数和 gadget 的偏移量（以便于将该漏洞利用移植到其他目标）

演示/截图

这是一个视频演示，展示了漏洞利用将 PC 修改为指向自定义地址：

该链的第一个迭代版本可以在 jop_experiment 中看到。这个链直接调用 execv，而不调用 fork。可以在提交 ca28fdf 中找到。以下是使用此链时发生的情况：

该链的第二个迭代版本是先调用 fork 再调用 execv。此链的完整细节可以在这里找到。以下是使用此链时发生的情况：

幸运的是，Pixel 3 XL 具有防护机制，可以阻止蓝牙进程调用 fork 和/或 execv。就知识分享或炫耀而言，我在这里的工作已经完成。如果我编写并分享更高级的内容，可能会对黑帽黑客过于有帮助。

漏洞利用总结

我认为这个漏洞利用已经完整。未来的改进方向可能包括：

• 编写一个 JOP 链，调用 dlsym 后再调用 mprotect，以运行自定义 shellcode
• 收集并保存不同目标的偏移量数据库
• 在多个目标上测试漏洞利用，以实现相对的通用性
• 将该漏洞利用与操作系统级漏洞利用链接起来以获得 root 权限（例如我之前 CVE-2019-2215 的漏洞利用）
• 以及更多……

所有这些都会将这个项目从一个有趣的知识分享项目变成一个可以武器化的黑帽漏洞利用，所以我的旅程到此为止，暂时……如果你有任何问题，请随时联系我。

用法

要运行该漏洞利用，只需运行：

make build run ARGS="00:00:00:00:00:00" 

其中 00:00:00:00:00:00 是目标/受害者设备的 MAC 地址。除了 make clean 之外，其余的构建目标只在你想修改、改进或重新实现该漏洞利用时才有帮助，因此无需深入介绍。

调试

• Android 的 gdbserver 二进制文件可以在 NDK 文件夹中找到
• 使用它来调试目标（不推荐）：

# On target
/data/local/tmp/gdbserver 0.0.0.0:1234 --attach $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}')

# On host
adb forward tcp:1234 tcp:1234
gdb-multiarch -q -x ./gdbinit

• 直接通过 termux 的 gdb 在手机上调试（推荐）：

# On host
adb push ./gdbinit /data/local/tmp/gdbinit

# On target
su
/data/data/com.termux/files/usr/bin/gdb -q -x /data/local/tmp/gdbinit -p $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}') 
# OR
/data/data/com.termux/files/usr/bin/gdb -q -p $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}') 

如果蓝牙服务停止工作，你可以在攻击者机器上重启它：

sudo systemctl restart bluetooth.service

备注

本节解释在开发此漏洞利用过程中观察到的一些现象：

• SSP 被关闭（在创建 HCI socket fd 时），以防止远程目标上发生超时：

• 我们正在喷射堆清理数据包，以降低目标因意外溢出而崩溃的概率，该溢出会修改通过 get_message_loop 使用的 base::MessageLoop 对象的 vtable：

• 这在 insinuator 的帖子中没有得到很好的解释。我们通过尝试定位 32 字节的 malloc 块来泄漏数据包的地址，这些块包含 partial_packets unordered_map 中每个项的一个链表项。这是通过 map_experiment 弄清楚的 map_experiment 与实际程序中泄漏的内容不匹配，所以我只是遵循了 insinuator 的模式，使用了另一种模式（这也是我通过实验发现的）。

• 崩溃和 PC 覆盖成功使 chrome 信号对象崩溃

• JOP 链已使用 jop_experiment 进行了模拟。完整的（第一个、仅 execv 的）JOP 链在 JOP_PLAN.md 中有详细说明