前言

自去年的 KCTF 以来，对 PWN 的认知渐渐发生了些许变化。刚开始入门的时候总希望着程序是精简而美观的，这样不会妨碍到自己在做题时的理解，但显然，并不是所有题目都是如此，也不是所有出题人都这么认为。随着接触到的内容越来越多，我渐渐不去关心程序本身是否美观了，因为那是一种奢侈，只要程序并不至于太大，总归是有办法的。

但是显然，越是接近真正的 PWN，或者说现实的 PWN，就会明白二进制体很小其实也是可遇不可求的，哪怕是各大比赛，都在往真实环境靠，依靠人力和反编译工具阅读代码变得越来越困难了。但或许大家都发现了，越是接近现实的 PWN 就越是无聊，如果 CTF Game 变得和现实里的挖洞没有区别了，那它还是 Game 吗？

出于这些考量，我希望能延续去年的方案，为选手直接或间接的提供源代码以供分析，并且将题目的关键点聚焦在 “漏洞利用” 而非 “漏洞挖掘‘。其实没有什么很强的目的性，但是不得不考虑的是，大部分漏洞挖掘的方式其实都比较千篇一律，但漏洞利用却能各不相同，既然是为了见识到更多的思考和技巧，那么还是从利用上提出问题比较令自己满意。(事实上，这两次KCTF中，我的题目都收获了让我意想不到的新奇做法，我觉得这种感觉很好，因为 CTF 本身就是一种对抗学习的比赛，出题人千方百计构造出的利用链完全有可能被选手以一种难以想象的方式攻破。)

最开始，我是基于 V8 出一道题的，但是出于各种现实因素，最终还是放弃了。
但浏览器相关的东西一直以来都很有意思，所以最后选了一个较为经典的 WASM 解释器作为范本进行修改。

出题思路

过去没接触过这些东西的时候对 WASM 还不敏感，但最近耳边相关的声音越来越多了，于是选了一个比较有代表性的项目作为样本进行魔改，也是希望选手能通过查询资料找到这个项目的源代码来加快分析：

https://github.com/wasm3/wasm3

整个项目的核心部分是用 C 语言编写的，并且代码量其实并不会特别庞大，相比于 V8 之类的 JavaScript 引擎，它要好上太多了。

大致阅读了一下代码逻辑可以发现，该项目支持很多不同的输入，而既然我们要以 WASM 作为游戏的关键部分，那自然要选择对 WASM 代码进行解析的部分作为主要内容了，大致逻辑如下:

• 读取输入的 WASM 字节码，交给 m3_ParseModule 按照模块进行解析
• 解析了输入模块以后，调用 m3_LoadModule 进行初始化设置
• 调用 link_all 将 WASI 模块链接进来
• 调用 repl_call 对模块中的函数实现进行调用，执行具体的字节码

每一个部分其实都适合插入漏洞，我最开始的想法是在字节码执行部分修改字节码的行为从而导致非预期的问题发生，但最终放弃了，因为它并不具备 JIT 的能力，并且所有的字节码都运行在内存隔离的环境下，无法对外界进行访问，而如果强行在这个地方注入漏洞，那一切就都会看起来非常突兀，并且题目会变得单一，这并非我希望的事情。

通过阅读第一部分的代码逻辑，我发现 WASM 字节码具有固定的格式，其中，对全局变量的访问实际上是通过数组索引进行的，最终编译在字节码中的字节其实就是一个索引。这非常有趣，因为它意味着用户输入可以不遵守编译器的阅读，而去构建非法的字节码进行越界。

事实上，我在使用 wat2wasm 对我的 exploit 进行编译时也发现，强行访问越界索引是会被编译器阻止的，以此为出发点，可以引导选手主动规避编译器的规范去构造恶意 WASM 字节码。

于是我修改了第一处代码，去除了对全局变量数组的扩展：

同时，还需要有一个地方能为全局变量进行初始化，我最终选定的目标是 ParseSection_Import ：

选择这里其实是有原因的，因为只有在这个地方去创建才能让题目可做，后文会提到为什么。

有了这两个点以后，似乎一切都变得比较自然了。因为全局数组的地址紧邻着由 Module_PreallocFunctions 创建的函数列表。在 M3Function 结构体中存在一个 compiled 成员，阅读 Call 指令的编译部分可以发现，如果该成员非零，就会认为该函数已被编译，可以直接跳转到 compiled 中储存的地址去：

一切是不是都看起来非常的自然，就好像我只需要用额外的 global 去覆盖 compiled 就足够的样子，但实际上是不行的，并且是理论上不可能实现的。

我在测试的时候发现，二者在内存上是不可能有重叠的可能性的。如下是 M3Global 结构体的定义：

用于储存具体数值的 i64Value 在内存上永远对齐了 0x10，而 compiled 则永远对齐到 0x08，不论如何覆盖都是不可能完成的，于是我还修改了一个点：

我让 M3Function 的 names 字段多加 8 个字节，这样是不是就能成功了呢？还是不行。经过笔者测试，如果二者在内存上直接相邻，那 i64Value 和 compiled 最小也会有 0x10 的偏移，似乎还是不能成功。

但如果他们之间相互并不紧邻的话，就会导致向下覆盖到其他结构体的数据，这会直接导致程序崩溃所以也要避免。

好在我发现有一种方案能够避开崩溃并且自由调节 i64Value 和 compiled 的偏移：

WASM3 按照这样的顺序解析字节码，而 Function 数组最早会在 ParseSection_Import 中根据导入的符号数进行创建，如果实际的函数数量超过了当前的数组容量，那么就会调用 realloc 重新开辟，通过调整内存布局就能够让二者中间留下无用的内存，这样就可以任意越界了。

但是只是这样还是无法完成利用。

我本以为这样看起来好像万无一失了，但经过调试发现，我无法泄露任何地址，因为在 m3_LoadModule 会解析全局变量的值，这会让原本就算有值的地方也被覆盖成自己声明的值，并且没有手段能够阻止它不去解析。

但笔者发现通过 Import 导入的全局变量并不会被解析，这样就不用担心本该泄露的值被覆盖了，但是这也很糟糕，因为其他成员会破坏函数的结构体，这会导致在 link_all 阶段程序崩溃。于是我做了第三个变动：

这将导致程序解析不再需要按照顺序读取模块，甚至模块可以重复导入。那么最终就可以在正常的 M3global 后面插入 Import Global，从而规避开内存破坏。

在有了以上这些操作以后，最终能够构建出差不多如下的代码：

其中有部分对全局变量获取的地方需要手动对编译后的字节码进行 patch 来调整输入，并且最终要在 export 段以后额外添加一份 import 段：

解题思路

解题思路其实就跟出题思路差不多了，唯一的区别就是在漏洞发现部分，选手可以用 bindiff 对程序进行对比，从而找出被修补后的代码部分，然后通过阅读二进制程序来还原源代码。

最终确立出如下两个变化：

• 全局变量越界
• 解析顺序随意

因为我对代码的改动其实很少，所以应该是比较容易能够发现问题的。

后续的利用就如前文所说了。

日后谈

其实对堆风水的细节调整笔者做了大量的调试，要比文中所说的麻烦的多，作为防守方我肯定是希望尽可能减少修改来提高难度的，但是有的时候如果不这么改又做不出来，又或者我能否再少改一些？或许是我把自己绕进去了吧。

最后也希望各位玩的开心，享受这个游戏的过程。

[培训]二进制漏洞攻防（第3期）；满10人开班；模糊测试与工具使用二次开发；网络协议漏洞挖掘；Linux内核漏洞挖掘与利用；AOSP漏洞挖掘与利用；代码审计。