前言

本文参考 buptsb 的 writeup ，大佬的分析文章已经足够清晰，但是对于一些利用细节总是一笔带过，对于像我这样的小白着实不友好，所以还是决定把自己的分析调试过程记录下来，以便日后查看

文章主要记录利用过程，漏洞原理参考文章已经非常清晰了

漏洞分析

patch 如下：


定位补丁代码上下文：

TryFastAddDataProperty 函数主要用于优化 prop 的添加，这里可以看当时引入该函数的 commit：

可以看到这里的优化主要依赖于 transition array 的，所以可以知道其是针对 fast object 的，因为 slow object[dict] 不存在 transition array

现说结论，这里的漏洞在于：

• 在 PrepareForDataProperty 函数中，对 map 进行 Update 后，没有检查其是否可能为 dict map
• 而在 Update 函数中存在逻辑可以将 map 迁移为 dict map，此时 fast object 变成 slow object
• 而在之前说了，该函数是针对 fast object 进行优化的，所以在后面会将对象当作 fast object，从而导致 fast object 与 slow object 的类型混淆

看后面的 DCHECK(!map->is_dictionary_map()); 是不是格外显眼，在 Debug 模式下会检查其不为 dict map，但是在 Release 模式下却没有检查

如何执行到漏洞代码分支

在之前的 commit 的 comment 中可以看到，该函数主要用于优化 AddProperty 和 CreateDataProperty 函数，这里的利用依赖于 CreateDataProperty 函数：

issues-40057609 中给了一种调用到 CreateDataProperty 函数的方案：

这里主要利用 ...spread 操作去创建一个对象，跟进该 issues中的内容可以知道该操作行为如下：

• 当以一个参数为 ...spread 时，会创建一个 CloneObject，其函数调用栈如下：

• 如果在 ...spread 操作后跟有其它 indexes，其函数调用栈跟第一种情况相同
• 第三种情况：即漏洞利用路径

Update 函数如何将 map 迁移为 dict map

先跟进 Map::Update 函数：

可以看到想要进入 target path，必须得通过 check1，即 map 得是 deprecated 的

然后进入 MapUpdater::Update：

可以看到这里我们可以走到 ConstructNewMap 函数去创建新的 map，跟进该函数：

在 【1】 会将 map 迁移为 dict map，这里的 maybe_transition 调试发现满足条件，关键就在于 CanHaveMoreTransitions 函数得返回 false：

这里会进入 【1】 分支，这里的 kMaxNumberOfTransitions = 1024 + 512;

最开始我们的 map 为非 dict map，所以这里的 raw_transitions 指针就是 kFullTransitionArray 类型

所以想要返回 false 就得让 number_of_transitions 大于等于 1024+512 = 1536，这个比较好办

总结一下上面的内容，想要触发漏洞得满足：

• 使用 ...spread 操作执行到漏洞分支
• old_map 得是 deprecated 的
• split_map 所在的 transition tree 的 number_of_transitions 得 ≥ 1024+512

根据上述条件写出 poc：

poc 主要参考上述文章，主要是感觉存在一些玄学问题搞了我很久

这里我们使用 getter 回调去填充 transition tree，这里稍微解释下 poc

1、为什么要先调用 cloneic_mega(source2);

这里其实是我之前少说了一个 check ，就在这里说了，懒得重新整合了

其实就是 TryFastAddDataProperty 中的一个检查：

可以看到这里搜索出来的 map 不能为 null：

所以这里我们先执行 cloneic_mega(source2); 去构建一个 map_p29 -> map_p30 的转移

不执行 cloneic_mega(source2); 则搜索出来的 map 为 null：

其它地方比如 【1】/【2】 处都注释了，具体可以自行调试，反正就是很玄学

• 【1】 处不能为 SMI，否则 old_map 为 stable_map
• 【2】 处必须加上一个 get 回调，否则 split_map 所在 transition tree 的深度为 10

poc 效果如下：

• 最开始 old_map 为 deprecated_map
  
• Update 后的 new_map 为 dictionary_map
  

可以看到在 WriteToField 之前会调用 MigrateToMap 更新 object 的 map 为 new_map，而此时的 new_map 为 dict_map，但是后面 WriteToField 仍然会将 object 当作 fast object，所以导致了 fast object 和 slow object 之间的类型混淆

漏洞利用

UpdateDescriptorForValue 报错问题绕过

直接运行 poc 程序会直接 Segmentation fault：

这里的 rax 其实就是 dict map 的 DescriptorArray，其是只读的，所以这里的写入会报错：

整个调用栈如下：

定位到源码如下：

所以这里我们需要避免进入 GeneralizeField 函数，这里存在两个绕过点，第一个无法使用，根据注释并且调试可以知道其值每次都是相等的，所以这里我们需要通过第二个 if 语句去绕过

这里的 【1】 处需要注意，这里的 map 已经是 new_map 了，其为 dict map

来详细分析下该如何进行绕过：

这里我们可以利用 【2】 处进行绕过，调试发现 IsNone() 返回的是 true，所以得让 other.IsDouble() 返回 true，所以我们对 details 的相关字段要求如下：

• KindFiled = 1 ==> kAccessor kind (: 这个原因我暂时不明
• RepresentationField = 2 ==> kDouble (：用于绕过和后面的写入

描述符数组结构如下：

所以 details 读取如下：

RDX = 0x1798 = 4 + 503*12 这里我调试的时候 source 数组的大小为 503，相关属性字段偏移如下：

这里写个脚本扫描下内存：

扫描结果如下：

在我的环境下， 502 能够完成利用（大小其实是 503，因为是从 0~502），index 的含义后面再说

WriteToField 任意偏移地址写

在进行写入之前，调用 `` 更新了 object 的 map 为 dict map，所以后但是写入是按照 fast object 进行写入的，NameDictionary 结构如下：

无语了，写到12点半，结果上传文件，失败后，直接崩了，之前写的东西全没了，无语，不想写了，有时间再补吧......贴个 exp