Chrome Js engine attack analysis
learning for js engine vulnerabilities
Chrome引擎漏洞分析及利用
漏洞编号:CVE-2018-17463
,在chrome 70版本中被patch,测试版本为69.0.3497.42 beta版,涉及的一些前置知识可以参考V8的内存布局和官方文档
漏洞介绍
V8的IR
层操作有很多的flag
,其中有一个flag
叫做kNowrite
,从简单的语义分析来看表示的就是没有进行写操作,事实上代表的意思就是拥有这个flag
的操作不会修改原有的属性,那么也就是说js engine
推测含有这个flag
的操作是可以进行一些深度优化的,比如说去掉它的类型检查:
1 |
|
但是事实并非如此,通过跟踪这个的底层调用我们可以发现一些问题,在JSCreateObject
函数中,通过跟踪调用可以发现最后调到了一个名为 JSObject::OptimizeAsPrototype
的函数上面,而这个函数可能会修改对象原型,了解JS的可以知道所谓的原型代表的其实是一种类似类的继承关系,也就是说这个操作会修改对象的类型,也就是Map
属性,通过runtime func
也可以确定(%DebugPrint
)
1 | o.inline; |
这样一来对象o
的内存属性布局也会随之改变,如果经过了优化之后的代码去掉了checkMap
节点的话,那么之后对于对象属性的访问就会按照之前的内存布局进行访问,举一个很简单的例子,可能在FastProperties
的时候想要访问属性编译成机器码之后如下所示:
1 | ;js code : return o.b |
但是此时作为DictionaryProperties
的内存布局在对应偏移的位置就可能不是原来的数据了,而是其他未知的数据,在分析create
操作前后的内存布局我们可以发现一个奇怪的事情:
1 | o.p0 = 0; o.p1 = 1; o.p2 = 2; o.p3 = 3; o.p4 = 4; |
那就是o.p6
和o.p2
这两个属性经过转换之后发生了重叠,这意味着我们在优化去掉了checkMap
节点之后访问o.p6
,实际上返回的是o.p2
的值。
稍微对于V8
的一些机制有了解的话就知道DictionaryMode
是通过hashfunc
来计算地址的,所以这个overlap
是哈希之后的结果,而这个哈希计算的方式是进程独立的,也就是我们每个进程都有着不同的哈希计算方式,这也就意味着我们如果找到了这个overlap
,之后就可以通过修改o.p2
来做到很多事情,比如说在o.p2
放置一个对象,那么返回的就是这个对象的地址了。
任意地址读写
这里的任意地址读写用的是两个ArrayBuffer
,首先来看看普通对象和ArrayBuffer
内存布局的对比:
上面的是ArrayBuffer
,下面是普通对象,可以看到backing_store
的偏移应该是对应的是普通对象的第二个inline
属性的偏移,所以如果我们在触发漏洞后,将对象的第二个对象内属性修改,就可以把这个backing_store
的值给修改,如果我们修改为指向另一个ArrayBuffer
,形成如下的结构:
1 | +-----------------+ +-----------------+ |
那么我们用第一个ArrayBuffer来new一个BigUint64
的数组,这个数组的地址事实上是ArrayBuffer
的数据,也就是backing_store
指向的ArrayBuffer2
,我们将数组的第五个元素,也就是backing_store
进行任意的设置可以指向任意的地址,然后切换到ArrayBuffer2
进行操作,再用ArrayBuffer2
来new一个新的数组,这个时候我们对数组进行的任何操作都是我们对于那个地址的任何操作,也就是所谓的任意地址读写了,稍微封装一下如下所示:
1 | //driver是ArrayBuffer2 |
这里只用一个ArrayBuffer
行不行呢?其实也是可以的,只不过每一次修改都用通过优化并触发漏洞来overlap
掉backing_store
,而两个ArrayBuffer
就只需要触发一次,可以节省很多开销并更加稳定
最后来看一下任意地址读的效果图,是在macOS上测试的:
之后的工作还有待完善,可以完全控制浏览器的控制流