CVE-2019-9810 Windows 版 Firefox 利用程序

CVE-2019-9810 是一个由 Richard Zhu 和 Amat Cama 在 Pwn2Own 2019 上发现并利用的漏洞。它影响了 Mozilla 的 JavaScript 引擎 Spidermonkey，并被用于实现渲染进程的攻破。

该问题已于大约两个月前在 mfsa2019-09 中修复。

问题概述

简而言之，该漏洞使得边界检查判定为冗余并被优化掉，从而允许代码访问越界内存。问题本身出在 Ion 管道的别名分析阶段。下图展示了 GVN 优化（边界检查被优化掉）过程中漏洞的后果，如果您正是想了解这一点，这可以说是一个很好的总结：

summary

不过，如果您想了解更多细节，我建议您阅读走进 IonMonkey：根因分析 CVE-2019-9810。

组织

该仓库包含 exploit 代码以及我之前为 blazefox 漏洞利用开发的一系列工具。我刚刚对它们进行了更新并使其兼容 BigInt。因此，该漏洞利用假定 Firefox 中已开启对 BigInt 的支持，您可以通过在 about:config 中切换 javascript.options.bigint 选项来实现。

bigint

该漏洞利用已针对 Windows RS5 64 位系统进行测试，并且它瞄准的是 Firefox 的自定义构建版本，所以如果要在其他地方运行它可能需要做一些额外的工作，请不要感到惊讶 :)。不过，如果您只想运行漏洞利用而不需要编译任何东西，我准备了一个打包好的浏览器，已上传到 release/firefox-68.0a1.en-US.win64.7z。其中还包含了 js.exe shell 以及 js.exe、firefox.exe 和 xul.dll 的私有符号信息。

如前所述，漏洞利用过程与我之前的 kaizen.js 漏洞利用非常相似。它会将执行流转发到实现 payload 的反射型 dll 的 ReflectiveLoader 上：

如果 payload 检测到它是由 js.exe 调用的，它只会向 stdout 持续输出 PWN，启动计算器然后退出。
如果它是在浏览器中运行的，它会先将自己注入到其他 Firefox.exe 进程中。为此，JavaScript 漏洞利用将一个指向反射型 dll 副本的指针传递过去，然后反射型 dll 将其映射到其他进程中。一旦完成这一步，它就会在反射型加载器上创建一个远程线程并休眠一会儿。这样做的原因是，当前状态下的漏洞利用比较粗糙，没有实现进程继续执行。不过，我认为要达到这一点其实工作量并不大。也许我以后会抽空做这件事 :-)。
当 payload 从其他 Firefox.exe 中执行时，它会内联钩子函数 xul!nsJSUtils::ExecutionContext::Compile。当需要由 JavaScript 引擎执行脚本时，这个函数会被执行；因此，对于我想做的事情来说，这听起来是一个足够好的候选点。钩子版本只是在脚本前面添加了一段任意 JavaScript payload 供我们选择。
放置好钩子后，它就直接返回了。此时，其他源已经被注入了任意 JavaScript。我使用的 payload 只是将这些源的背景图片替换为逆向工程师日记的主题图片，同时将所有链接重定向到该博客 :)。

实际上，上面描述的内容还遗漏了许多更微妙的细节，所以如果您感兴趣，可以自己去寻找真相并阅读源代码 :)。

构建 payload

要构建 payload，只需在 VS 2017 x64 提示符下运行 nmake。

CVE-2019-9810\payload>nmake

Microsoft (R) Program Maintenance Utility Version 14.16.27027.1
Copyright (C) Microsoft Corporation.  All rights reserved.

        ml64 /c src\trampoline.asm
Microsoft (R) Macro Assembler (x64) Version 14.16.27027.1
Copyright (C) Microsoft Corporation.  All rights reserved.

 Assembling: src\trampoline.asm
        if not exist .\bin mkdir bin
        type injected-script.js > src\injected-script.h
        cl /O1 /nologo /W3 /D_AMD64_ /DWIN_X64 /DREFLECTIVEDLLINJECTION_CUSTOM_DLLMAIN /Febin\payload.dll src\ReflectiveLoader.c src\ReflectiveDll.cc trampoline.obj /link /DLL /nologo /debug:full /PDBALTPATH:%_PDB%
ReflectiveLoader.c
Generating Code...
Compiling...
ReflectiveDll.cc
Generating Code...
   Creating library bin\payload.lib and object bin\payload.exp
        python jsify_payload.py bin\payload.dll
        move payload.js ..
        1 file(s) moved.
        del *.obj
        del src\injected-script.h
        if exist .\bin del bin\*.exp bin\*.ilk bin\*.lib

这会在 payload\bin 目录下生成 payload.dll / payload.pdb 文件，以及一个名为 payload.js 的 JavaScript 文件，该文件将 dll 嵌入到一个 Uint8Array 中，并包含加载器的偏移量。

构建 Firefox

我针对本地 Windows 构建版本编写了这个漏洞利用，该版本同步到了以下修订版 ID：2abb636ad481768b7c88619080cf224b2c266b2d（如果您不想自己构建，我在这里上传了我的构建版本：release/firefox-68.0a1.en-US.win64.7z）：

$ hg --debug id -i
2abb636ad481768b7c88619080cf224b2c266b2d

我使用了以下 mozconfig 文件：

. "$topsrcdir/browser/config/mozconfigs/win64/common-win64"

ac_add_options --disable-crashreporter
ac_add_options --enable-debug-symbols

. "$topsrcdir/build/mozconfig.clang-cl"
. "$topsrcdir/build/mozconfig.lld-link"

# Use the clang version in .mozbuild
CLANG_LIB_DIR="$(cd ~/.mozbuild/clang/lib/clang/*/lib/windows && pwd)"
export LIB=$LIB:$CLANG_LIB_DIR

ac_add_options --enable-js-shell
ac_add_options --enable-jitspew
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff64

讨论

虽然对我来说已经够用，但我不确定 xul!nsJSUtils::ExecutionContext::Compile 是否是插入任意脚本的最佳函数。我相信，如果花更多时间深入了解 xul 前端的工作原理，或许能找到一个更好的钩子点。

另外，在编写漏洞利用之后，我还发现了一些其他途径，这些内容在 Bugzilla 条目 982974 中有所讨论（JavaScript 解释器的系统主体以及 security.turn_off_all_security_so_that_viruses_can_take_over_this_computer）。看看其中有多少内容至今仍适用于 Firefox 会很有趣。

也许已经有人研究过这个主题而我完全错过了。无论如何，欢迎随时联系我提供任何反馈！

另一个有趣的事情是探索是否有可能在浏览器内部实现持久化机制。我完全没有研究过这个领域，但那会很酷 :)。