@

前言

最近在学习 Maglev 相关知识，然后看了一些与其相关的 CVE，感觉该漏洞比较容易复现，所以先打算复现一下，本文还是主要分析漏洞产生的原因，基础知识笔者会简单说一说，更多的还是需要读者自己去学习

这里说一下为什么笔者不愿意在漏洞分析中写过多的前置知识，因为笔者认为读者都已经开始复现漏洞了，那么对基础知识应当是有一定的了解了，并且笔者的基础也比较差，所以不希望误人子弟，网上的资料很多，自己学学就 OK 啦

环境搭建

前置知识

new 关键字： new func() 效果为：

• 创建一个默认对象 this，然后进行初始化 this.prop = val
• 若 func 本身返回一个对象，则抛弃默认对象；否则返回默认对象

这里给一个示例代码：

new.target 这里自行看资料

Reflect.construct(target, argument, new_target) 函数以 target 为构造函数创建对象，这里 new_target 提供原型，然后行为跟 new func() 类似

上面的知识都比较简单，所以也不想细说了，如果读者不是很清楚的话，请自行查阅下相关资料吧，这里主要关注 JS 引擎层面的实现

对于默认对象，其是通过 FastNewObject 函数创建的，其调用链如下：

先来看看 TF_BUILTIN(FastNewObject, ConstructorBuiltinsAssembler)：

该函数比较简单，其主要就是调用了 ConstructorBuiltinsAssembler::FastNewObject 函数：

可以看到 ConstructorBuiltinsAssembler::FastNewObject 分为快速路径和慢速路径：

• 快速路径：直接根据 new_target 的 initial_map 进行默认对象的创建
  • initial_map 的构造函数与 target 相同
  • new_target 的 initial_map 为一个有效 map
• 慢速路径：调用 Runtime::kNewObject 运行时函数

这里的快速路径可能有点奇怪？因为这里 target 才是构造函数，所以默认对象的 map 再怎么说也不应该与 new_target 的 initial_map 相同，但这其实是一个优化，其会将 target 的 initial_map 和 new_target 的 prototype 缓存在 new_target 的 initial_map 域，这个后面再说

然后可以看到走快速路径是存在两个条件的，不满足则会走慢速路径 Runtime::kNewObjec：

可以看到其直接调用了 JSObject::New 函数：

在 【1】 处会调用 JSFunction::GetDerivedMap 函数，这里的 constructor 传入的是 target：

可以看到其会调用 FastInitializeDerivedMap 为 new_target 创建 initial_map：

可以看到在 【2】 处设置了 new_target 的 initial_map 为 map，但是修改了 prototype 为 new_target 的 prototype， constructor 为 target。而该 map 在 【1】 处是通过复制 constructor_initial_map 来的，看到这里可能就明白了之前快速路径的逻辑

所以在快速路径中，当 new_target.initial_map.constructor = target 时，则说明 new_target.initial_map 与 target.initial_map 是相同的，所以这里就会直接使用 new_target.initial_map

OK，以上就是后面漏洞分析需要的一些基础知识

漏洞分析

还是先从 patch 入手：

从补丁打的位置可以知道该漏洞应该发生在 Maglev 的图构建阶段，并且其主要打在了 MaglevGraphBuilder::VisitFindNonDefaultConstructorOrConstruct 函数中，根据函数名大概知道其主要就是处理 FindNonDefaultConstructorOrConstruct 字节码的，而该操作的功能为“寻找非默认构造函数”，这里结合 chatGPT 食用：

在 V8 引擎中，FindNonDefaultConstructorOrConstruct 字节码指令用于查找非默认构造函数或构造器函数。这个字节码指令在 JavaScript 代码中的类构造过程中使用。

当在 JavaScript 中创建一个类并调用 new 关键字来实例化对象时，V8 引擎会执行相应的字节码指令序列。其中，FindNonDefaultConstructorOrConstruct 字节码指令用于查找适当的构造函数或构造器函数。

具体而言，该指令会检查类的原型链以查找适合的构造函数。它首先尝试查找类自身的 constructor 属性，如果找到则使用该构造函数。否则，它会沿着原型链向上查找，直到找到一个非默认构造函数或构造器函数。

这个过程是为了确保在类继承链中正确地选择构造函数，以便在实例化对象时执行相应的初始化逻辑。

所以可以写出如下代码去生成目标字节码：

来看下 B 产生的字节码：

可以看到这里确实生成了 FindNonDefaultConstructorOrConstruct 字节码，其实可以把它看成一种优化，其会遍历 B 的原型链，尽量的忽略哪些默认构造函数，如果最后到达原型链顶层，则调用 FastNewObject 创建默认对象

现在我们回到主要的补丁代码：

可以看到这里的补丁仅仅对 new_target 的 initial_map 进行了检查，而之前的漏洞代码并没有对 new_target 的 initial_map 进行合法性检查，我们看下这个函数的关键逻辑：

可以看到如果最后到达顶层构造函数，并且 new_target 是一个 JSFunction 对象，则会调用 BuildAllocateFastObject 进行默认对象的创建，而不是调用之前分析的 TF_BUILTIN(FastNewObject, ConstructorBuiltinsAssembler) 函数进行创建，但是这里调用 BuildAllocateFastObject 时，没用对 new_target 的 initial_map 进行合法性检查，然后这里第一个参数是通过 FastObject 构造函数创建的，跟进看看：

注意我们传入的参数是 new_target_function，所以可以看到这里的 map 就是 new_target_function.initial_map

然后可以跟进 BuildAllocateFastObject 函数看看：

该函数有多个实现，可以根据参数类型判断具体调用了那个函数

所以这里的关键点就是其把默认对象的 map 设置为了 new_target.initial_map，这便是漏洞之处，通过之前的分析我们知道，调用 BuildAllocateFastObject 函数之前没有对 new_target.initial_map 进行合法性检查，所以最后可以导致的效果为：

• 创建了一个 new_target.initial_map 类型的默认对象 obj
• 对默认对象 obj 的初始化由 target 完成

那么这时如果 new_target 与 target 的 initial_map 不相同，则可能导致属性初始化错误，比如 new_target 的 initial_map 为 JSArray，那么此时就会导致 target 忽略对默认对象 length 属性的初始化

漏洞触发

想要到达漏洞代码逻辑，得使以下关键判断成立：

先来看下 TryGetConstant 函数：

注：这里 TryGetConstant 存在多个实现，但没办法用参数进行判断调用了哪一个，所以这里参考参考文章的分析

由于还没开始审计 Maglev 源码，所以这里笔者不是很懂，简单来说就是这里有两个路径可以进行判断 node 是否是 constant：

• 【1】：该路径直接检查 node 是否是一个 global constant
• 【2】：检查是否有其它 nodes 标记该 node 是一个 constant

这里 【1】 路径行不通，所以这里利用【2】路径进行绕过，其主要就是插入一个 CheckValue 节点，而该节点会标记该 node 为一个 constant：

这里直接看 poc：

看下 Maglev IR：

可以看到这里确实产生了 CheckValue 节点，并且这里可以看 Map 的值：

可以看到其直接赋值的 new_target.initial_map，而 new_target.initial_map 的类型为 JSArray：

来看下初始化过程：

这里的 4/8 明显是 properties/element 的偏移，但是其却没有对 length 进行赋值，可以看到print(arr instanceof Array) 输出的是 true，即 arr 是一个数组：

漏洞利用

这里主要利用的是 JSObject 与 JSArray 的类型混淆，JSObject 是不存在 length 属性的，而 JSArray 存在 length 属性，所以如果 target 为 JSObject，而 new_target 为 JSArray，那么触发漏洞后，target 就不会初始化创建对象的 length 属性，所以这里的 length 就是一个未初始化的值，如果这个未初始化 length 值比较大，就可以实现越界读写

有了越界读写，后面写利用就比较简单了，很多利用手法都大同小异，所以就不细说了，主要说下关键点：

• 虽然没有对 length 进行初始化，但是一般（没有 gc）时，length 就为 0，所以这里先提前触发 gc 去移动对象，这样有概率存在残留数据覆盖 length，如果 length 比较大，就可以实现越界读写

• 由于 JSObect 对象不使用 element 属性，所以这里 element 指向 FixedArray[0]，其值在笔者机器上固定为 0x219，其属于的页权限为只读权限，但是这里问题不大，因为 0x219 基本就在堆的最低地址处了，只要被覆盖的 length 比较大，就可以实现越界读写

exploit 如下：

效果如下：

总结

通过对该 CVE 的分析利用，对 Maglev 有了基本的了解，但是还有一些细节上的东西没有搞清楚，这个只能后面对 Mgalev 逐渐熟悉后再看看了

然后看了下腾讯玄武去年的 talk，发现 Maglev 是一个很不错的攻击面（玄武的大佬好像直接挖了7个洞），其与 trubofan 有部分相同的性质，而其又具有独特的攻击面，所以笔者感觉可以将 turbofan 的一些历史漏洞去套下 Maglev。当然了，随着 chrome 对 turbofan 保护强度的逐步上升，目前想在 trubofan 中出一个洞可以说是非常难了，而 Maglev 应该是目前最能够出 JIT 洞的了，当然自己目前太菜了，也希望早日能够挖到自己的漏洞

说点别的，瞎扯一下：目前其实也复现了很多漏洞，但是对挖漏洞其实还是比较迷茫的，自己也花了一些时间总结了下，发现自己虽然在复现一些漏洞，但是很多漏洞都比较老，并且在复现漏洞的时候没有去总结可能的攻击面，看了很多大佬的 talk，发现选取攻击面是非常重要的，就 chrome 而言，其有很多组件，每个组件又有不同的功能分支，如何针对性的进行 fuzz 是非常重要的。也希望后面可以跟踪一些比较前沿的攻击手法和比较新的攻击面。目前在笔者看来，复现漏洞就两个目的，第一就是熟悉某个知识点，就比如笔者之所以复现该漏洞其实就是为了巩固下 Maglev 中的一些东西；第二就是总结攻击面，这个目前笔者做的比较失败。然后单纯的为了写利用去复现漏洞是没有意义的，漏洞那么多，是不能全部复现的。所以后面笔者复现漏洞也会有针对性的复现，会尽量选取一些比较新的漏洞进行复现

人一定要学会反思，不然就如同行尸走肉一般

参考

Getting RCE in Chrome with incomplete object initialization in the Maglev compiler

[培训]《安卓高级研修班(网课)》月薪三万计划，掌握调试、分析还原ollvm、vmp的方法，定制art虚拟机自动化脱壳的方法