95、漏洞利用开发（五）：浏览器漏洞利用、JavaScript引擎逆向

浏览器漏洞利用，说实话，是漏洞利用开发里最难啃的骨头之一。我做了这么多年逆向，每次碰到浏览器层面的东西，都得打起十二分精神。为什么？因为浏览器太复杂了，攻击面大得吓人，而且现代浏览器都有各种缓解措施——ASLR、DEP、JIT hardening、沙箱隔离……一个比一个难缠。

但话说回来，浏览器漏洞利用也是最有价值的。你想想看，一个能远程攻破Chrome或Firefox的exploit，在黑市上能卖到什么价？嗯，我不说你也懂。今天我们就来聊聊JavaScript引擎逆向，这是浏览器漏洞利用的核心中的核心。

1. 浏览器漏洞利用的基本思路

浏览器漏洞利用，说白了就是三步走：

  1. 找到漏洞——通常是UAF（Use-After-Free）、堆溢出、类型混淆这些老面孔
  2. 构造原语——把漏洞转化成可控的读写能力（addrof、fakeobj、任意地址读写）
  3. 绕过缓解措施——搞定ASLR、DEP、沙箱，最终执行shellcode

我个人习惯把重点放在第二步。因为很多新手拿到一个漏洞，能触发crash，但不知道怎么转化成exploit。这一步，说白了就是跟JavaScript引擎的内部数据结构打交道。

核心观点： 浏览器漏洞利用的本质，是操纵JavaScript引擎的内存布局，让引擎把我们的数据当成对象指针来解析。

2. JavaScript引擎逆向入门

目前主流的JS引擎有四个：V8（Chrome）、SpiderMonkey（Firefox）、JavaScriptCore（Safari）、Chakra（Edge，已退役）。我主要搞V8和SpiderMonkey，今天以V8为例来讲。

V8的核心架构其实不复杂：

  • Parser：把JS源码解析成AST
  • Ignition：解释器，把AST编译成字节码
  • TurboFan：JIT编译器，把热点代码编译成机器码
  • GC：垃圾回收器，管理内存

漏洞利用最常打交道的是对象模型和JIT编译过程。为什么？因为对象模型决定了内存布局，JIT编译过程则可能引入类型混淆。

我的经验： 刚开始逆向V8时，我建议先看对象的内存布局。V8的对象在内存中就是一个指针（Map指针）+ 若干个属性槽。搞懂这个，你就知道怎么伪造对象了。

3. V8对象模型深度解析

V8的对象在内存中长什么样？我画了一张图，你一看就明白：

V8 对象内存布局 Map 指针 (8字节) 指向隐藏类 属性槽 1 (8字节) 可以是Smi/指针/双精度 属性槽 2 (8字节) 可以是Smi/指针/双精度 ... 更多属性槽 长度由Map决定 Map 结构详情 实例大小、属性偏移、类型信息 属性槽值类型 Smi: 值直接存储 HeapObject: 指针 注意：V8中所有对象都以8字节对齐，Smi最低位为0，HeapObject最低位为1

这张图里最关键的是Map指针。Map指针指向一个隐藏类对象，它描述了对象的类型、大小、属性布局等信息。V8用Map来做类型检查和属性访问优化——这也是类型混淆漏洞的根源。

举个例子，如果某个操作把A类型的对象当成B类型来用，Map指针就指向了错误的Map，引擎就会按照B的布局来解析A的内存。嗯，这就是典型的类型混淆。

4. 常见漏洞类型与利用手法

浏览器漏洞利用中，我遇到最多的三类漏洞：

漏洞类型 触发方式 利用难度 经典案例
UAF (Use-After-Free) 对象释放后仍保留引用 中 CVE-2021-30551
类型混淆 JIT优化时类型推断错误 高 CVE-2019-13764
堆溢出 数组/字符串边界检查缺失 中低 CVE-2020-16040

我个人觉得，类型混淆是最有意思的。因为它往往出现在JIT编译器的优化过程中，需要你深入理解TurboFan的编译流程。我曾经花了两周时间逆向一个TurboFan的bug，最后发现是Simplified Lowering阶段的一个类型推断错误——那种感觉，就像在迷宫里找到了出口。

注意： 现代浏览器的JIT hardening越来越强。比如V8的指针压缩（Pointer Compression）和隔离堆（Isolated Heap），让传统的类型混淆利用变得困难。你需要不断更新知识库。

5. 实战：从类型混淆到任意地址读写

好，我们来看一个具体的例子。假设我们找到了一个类型混淆漏洞，能把一个double数组误认为object数组。怎么利用？

在V8中，数组的元素存储方式有两种：

  • FastDoubleElements：元素直接存double值（8字节）
  • FastObjectElements：元素存对象指针（8字节）

如果类型混淆发生，我们可以用double数组的索引去读写object数组的内存。具体来说：

// 假设我们有一个类型混淆的数组 arr
// arr 在内存中被当作 FastObjectElements 数组
// 但实际上它是 FastDoubleElements 数组

// 1. 获取任意对象的地址（addrof原语）
function addrof(obj) {
    // 把obj放到混淆数组的某个位置
    arr[0] = obj;  
    // 以double形式读取，得到的就是obj的地址
    return arr[0];  
}

// 2. 伪造对象（fakeobj原语）
function fakeobj(addr) {
    // 把地址以double形式写入
    arr[0] = addr;  
    // 以object形式读取，得到一个指向addr的假对象
    return arr[0];  
}

// 3. 任意地址读写
// 有了addrof和fakeobj，就可以构造任意地址读写原语
// 具体做法：伪造一个ArrayBuffer，修改其backing_store指针

这段代码看起来简单，但实际利用时坑很多。我曾经在调试一个Chrome exploit时，发现addrof返回的地址总是少2位——后来才意识到V8的指针压缩把高32位截断了。嗯，这种细节问题，不踩坑是学不会的。

避坑指南： 我曾经在V8 8.0版本上调试一个类型混淆漏洞，发现伪造的对象总是crash。后来排查了两天，才发现是V8的Map验证机制——伪造对象的Map指针必须指向一个合法的Map。解决办法是：先泄露一个真实对象的Map，然后复制过来。

6. 绕过缓解措施

有了任意地址读写，不等于就能执行shellcode。你还要面对：

  • ASLR：地址随机化。用信息泄露搞定，比如通过addrof泄露某个已知模块的地址，然后计算基址。
  • DEP：数据执行保护。用ROP（Return-Oriented Programming）绕过，或者用JIT代码页（V8的W^X保护越来越严，这条路越来越窄）。
  • 沙箱：浏览器进程隔离。需要配合另一个漏洞（比如IPC漏洞）来逃逸沙箱。

我个人觉得，沙箱逃逸是目前最大的挑战。Chrome的沙箱做得非常完善，单靠一个渲染进程的漏洞很难直接拿到系统权限。你需要找到浏览器内核（Browser Process）的漏洞，或者利用Mojo接口的缺陷。

7. 逆向工具与调试技巧

做JS引擎逆向，我常用的工具：

  • d8：V8的独立shell，支持--allow-natives-syntax和--trace-turbo等调试选项
  • GDB + V8的pytools：可以打印V8内部对象，比如job命令打印JSObject
  • Turbolizer：可视化TurboFan的编译图，对理解JIT优化非常有帮助
  • rr (Record and Replay)：可逆调试，对分析crash特别有用

调试技巧方面，我建议你：

  1. 先用--trace-turbo导出JIT编译日志，分析优化过程
  2. 用%DebugPrint(obj)打印对象详细信息
  3. 在GDB中设置v8::internal::Isolate::Throw的断点，捕获异常
  4. 用--print-code查看JIT生成的机器码
我的习惯： 每次分析新漏洞时，我都会先写一个PoC，然后用--trace-turbo和--print-code把整个编译过程dump出来。这样能快速定位到漏洞触发的具体阶段。

8. 总结与思考

浏览器漏洞利用，说白了就是一场猫鼠游戏。浏览器厂商不断加固，攻击者不断寻找新的攻击面。从JIT漏洞到解释器漏洞，从类型混淆到数据竞争，攻击手法在进化，防御手段也在进化。

我做了这么多年，最大的感受是：不要只盯着漏洞本身，要理解引擎的设计哲学。V8为什么用指针压缩？为什么引入写屏障？为什么TurboFan要做范围分析？理解了这些设计决策，你才能找到它们的薄弱环节。

最后，送你一句话：逆向工程不是背套路，是理解系统。每个漏洞背后，都有一段被忽视的边界情况。找到它，你就赢了。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →