本文为CVE-2018-17463的分析以及复现，CVE-2018-17463是一个由于TurboFan优化所产生的漏洞，因为我也是刚接触浏览器这方面不久，是个新手，也是第一次复现真实环境中的漏洞，所以我会尽可能的把分析的过程以及自己在复现过程中遇到的问题写清楚，希望能够帮助到和我一样刚入门的师傅。

本文参考文章：http://p4nda.top/2019/06/11/%C2%96CVE-2018-17463/?utm_source=tuicool&utm_medium=referral#%E7%8E%AF%E5%A2%83%E6%90%AD%E5%BB%BA

这个漏洞在Chrome Bug的网页上，有很多的相关信息，我们可以在其中找到存在漏洞的版本，可以看到相关的PoC，为我们的复现做准备，这里放一下链接(第一次复现不了解，当时找链接找了半天)：

基础的V8调试环境的搭建这里就不再赘述了，需要的师傅可以参考我博客里的这一篇文章：v8调试环境搭建/)，讲的是Ubuntu22.04下的环境搭建。

用如下命令先切换到漏洞所在的版本并编译v8：

官方给出的PoC如下：

这里首先创建了一个名为f的函数，其中参数o是一个对象，在函数中调用了Object.Create(o)，并返回o.y.a，Object.create(o)会以其中的参数o为原型，再创建出一个对象并返回，但是这里并没有接收返回值，说明返回的对象并不是重点。接下来调用了两次f函数，然后通过%OptimizeFunctionOnNextCall来触发优化，最后再次调用f函数，并判断返回值是否与3相等。

根据传入的参数可以看出，在f函数并未修改o.y.a的值的情况下，最后一次调用f函数，返回的应该是3，说明这里由于某种原因o.y.a的值被改变了，而在PoC中，只调用了Object.create，那么很明显正是这个函数直接或间接引起了值的改变。

根据官方给出的补丁：

补丁中可以看出，用kNoProperties代替了kNoWrite，那么为了了解kNoWrite是个啥，我们需要在源码中进行查看，在operator.h文件中，我们可以发现kNoWrite定义在一个枚举类型中：

其中kNoWrite的注释的大致意思是：不会产生副作用而创造出一个新的依赖项，根据前面的PoC文件，我们可以看出，简单的调用Object.create()并不会导致值的改变，但当优化之后，值却改变了，再根据补丁文件可以看出CreateObject这个函数被kNoWrite所标记，所以我们可以猜测出CreateObject被认为是不会产生副作用的，为了进一步了解发生了什么，我们需要借助一个工具：Turbolizer。。

通过增加参数来生成Turbolizer所需要的文件：

然后运行Turbolizer：

将生成的json文件打开就行了，经过观察以后发现，CreateObject节点在generic lowering阶段，变为了Call：

鼠标放上去就能看见这里用CreateObjectWithoutProporties来代替了原本的JSCreateObject函数，那么我们继续查看源码(由于本人水平有限，源码阅读部分的分析大多是参考的参考文章中的描述)。

在builtins-object-gen.cc中：

从源码中可以看出，call_runtime函数实际上又调用了另一个Runtime::kObjecrCreate函数，它的源码在runtime-object.cc中：

可以看到，当O的类型是一个Object或者Null的时候，就会调用JSObject::ObjectCreate，他的位置在源码中的objects.cc：

可以看出，这段代码首先获取了Map，并根据Map的类型来选择调用NewSlowJSObjectFromMap或者NewJSObjectFromMap，我们跟进GetObjectCreateMap函数中继续观察：

这里如果满足prototype->IsJSObject()并且如果!js_prototype->map()->is_prototype_map()，那么将会调用优化函数JSObject::OptimizeAsPrototype来进行优化，我们继续跟进源码看：

这里可以看见，如果enable_setup_mode为真，并且PrototypeBenefitsFromNormalization()的返回值也为真的话，将会调用JSObject::NormalizeProperties，其中关于PrototypeBenefitsFromNormalization的判断可以看见，我们的对象需要拥有FastProperties并且满足下面的一些条件即可：

我们继续跟进NormalizeProperties来看看到底发生了什么，源码如下：

可以看见，该函数会根据现有的map通过Map::Normalize生成一个新的new_map，那么我们前面讲过，CreateObject被kNoWrite所标记，被认为是不会产生副作用的，但是在这里，如果new_map与map不一致，就会产生副作用，我们继续跟进Map::Normalize看看是否改变了Map：

当不满足条件：use_cache && cache->Get(fast_map, mode).ToHandle(&new_map)时，将会产生新的Map：new_map = Map::CopyNormalized(isolate, fast_map, mode);，这里use_cache我个人猜测应该是检索是否已有的Map，因为在v8中，Map不被使用时，通常不会被直接移除，因为可能会在后面使用，我们继续跟进CopyNormalized，来看看map是否变化：

可以看见其中调用了RawCopy函数，并且我们可以看见其中存在一个result->set_is_dictionary_map(true);，我们跟进这个函数去看看：

这个函数调用了Update，将Map更新为dictionary map，那么很显然，CreateObject函数并不是kNoWrite的，那么漏洞为什么会出现也很清楚了：当调用Object.create 时，然后由于错误的被标识为kNoWrite，并且在优化过程中被替换为CreateObjectWithoutProperties，又由于优化过程中省略了一系列的检查，没有探测到Map的改变，从而导致了漏洞的产生。

由于优化过程中，JSCreateObject被认为是kNoWrite的，所以只要我们先访问一次对象的某一个元素，在接下来访问另一次时，将会由于优化省略了CheckMap这一步，导致仍然按照原来的偏移去取值，导致取出的值并不是真正的值，我们可以构造如下代码：

成功触发漏洞：

我们首先写一段测试代码来观察一下Object.create前后的内存布局：

使用命令：

这时可以看见obj对象在内存中的布局如下：

这里我们可以很清楚的看见map从FastProperties变为了DictionaryProperties，学过基础知识的应该知道FastProperties模式的值，是直接存储在结构体中的，而DictionaryProperties模式的值，则是存储在一张hash表中的，我们可以查看DictionaryProperties模式的内存结构如下：

可以看见，hash表的排列是以0x10个字节为单位的，前0x8是名字，后0x8是名字，并且在测试过程中可以发现，由于随机化的影响，hash表每次的排列都是不同的既相同元素的偏移每次都不一样，这里怎么办我们后面再来说。

我们先看一下按照原本的偏移，Properties中存储了c，d两个变量：

可以看见，在0x8和0x10偏移的位置分别放了c，d的值，那么当他转换为hash表存储时，理论上来说，只要数据够多，原来的偏移处，一定会存在一个新的数据，假如新的数据的属性名为x，原来的数据名为y，那么当出现上述情况时，我们对y操作，实际上就是在对x操作，可以达到类型混淆的效果，那么我们通过以下代码创建多个属性并寻找相应的x与y(这段计算x与y的代码，参考自参考文章，因为我的代码不知道为啥一直算不出来)：

这里解释一下这段代码，首先按照规律：456-i的规律为每个属性bi赋值，然后将值存入数组obj_array中，然后开始循环，外层循环是为了触发优化，内层循环则是比较每一次obj.bi的值是否改变，如果改变了，则j以及456-array[j]即是我们需要找到x与y。

当我们找到x与y后，我们可以通过另一个规律：不同对象的相同属性名的属性在hash表中的位置是一致的来解决hash会变化的问题，我们来创建两个具有相同属性名的对象，来观察他们在内存中的结构：

在gdb中跑起来之后，我们可以用job命令来查看他们的hash表结构：

我们可以观察到，虽然obj1与obj2是两个不同的对象，但是他们相同名字的属性在hash表中的偏移却是相同的，那么根据我们上面找到的x与y，我们就可以创建另一个对象new_obj，并根据x与y来对new_obj进行类型混淆，达到泄露地址的目的，我们先写出泄露地址的原语：

其中C1，C2就是我们找出的x与y，我们先通过与之前一样的方式为一个对象添加大量属性，与之前不同的是，我们在C1加入属性c10，c11，并向C2中的c20存入一个对象，这样在我们返回C1.c10时，就会把C2.c20处存储的对象的地址作为浮点数返回，造成地址泄露。这里说一下为什么要以Obj.c2={c20:target}这种方式放入，因为如果直接放，我们泄露出来的并不是这个对象的地址，而是他的Map，这里可以自己调试一下看看就能明白。

然后我们需要任意地址写入，方法与leak差不多，只是我们在创建时，不能obj.C1 = {c11:1.1,c12:2.2}这样了，因为我们写是需要些对象的某个元素写入，那么我们可以按照如下方法构造：

这样让obj.C1.c10对应obj.C2.c20，那么我们操作c10的元素，就可以实现对target的属性的操作，而我们希望操作的是DataView的backing store，这样就可以利用dataview实现任意地址写，代码如下：

与前面任意地址读是差不多的，这时，我们就可以找到wasm的rwx段，并向其中写入我们的shellcode了，先对wasm初始化：

wasmCode我是采用在线网站生成的：https://wasdk.github.io/WasmFiddle/，直接用它默认的那个return 42就行，在初始化之后，我们需要找到rwx段所在的位置，这个调试慢慢找就行了，我这里给出我找到的路线：

然后利用dataview写入shellcode就可以了。
最终exp如下：

成功弹出计算器(跑起来慢的离谱，因为循环太多了，直接用%OptimizeOnNextCall来触发应该也行，我没试)：

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课