Edge Inline Segment Use After Free漏洞分析-安全客

Author:Qixun Zhao(aka @S0rryMybad && 大宝) of Qihoo 360 Vulcan Team

在今个月的微软补丁里,修复了我报告的4个漏洞,我将会一一讲解这些漏洞.因为我写的这些文章都是用我的空余时间写的,因为每天还有大量的工作和需要休息,而且这个博客也是一个非公的私人博客,所以我不能保证更新的时间.

这篇文章讲的是CVE-2018-8367,大家可以从这里看到这个bug的patch. 这是一个品相非常好的UaF,所以利用起来比较简单.同时这也是JIT中一个比较特别的漏洞,因为它需要其他模块的配合,希望能为大家以后寻找JIT漏洞的时候带来一些新思考

测试版本:chakraCore-master-2018-8-5 release build(大概是这个日期下载的就可以了)

关于Chakra的垃圾回收(GC)

要找到chakra中的UaF漏洞,首先需要了解chakra引擎的gc是怎么执行的.简单来说,chakra用到的gc算法是标记-清除(mark-sweep)算法,更详细的细节我推荐大家可以看看<<垃圾回收的算法与实现>>.

这个算法的核心在于有一堆需要维护的根对象(root),在chakra中根对象主要包括显式定义的脚本变量(var/let/const)还有栈上和寄存器的变量.算法从根对象开始扫描,并且递归扫描他们中的子对象(例如array对象中的segment就是array的子对象),直到遍历完所有的根对象和子对象.标记阶段完成后,如果没有标记的对象就是代表可以释放的,这时候内存管理器就会负责回收这些对象以用来以后的分配.

Chakra的gc算法主要有两个缺陷,第一是没有区分数字和对象,所以利用这个特性通过在栈上分配大量数字,然后通过侧信道攻击可以获得某个对象的地址.(这是我之前听过的一种攻击方法,不知道现在修补没有)

第二个缺陷在于,gc算法遍历子对象的时候,是需要知道父对象的大小的,不能越界遍历标记(例如父对象是array的时候,需要知道array的大小去递归标记).所以如果一个对象A中假如有一个指针指向另一个对象B的内部(非对象开始位置),A中的指针是不会执行标记操作的.假如除了对象A中的指针没有其他任何指针指向对象B,B对象是会被回收的.这样在A对象中就有一个B对象的悬挂指针(Dangling Pointers).

寻找UaF漏洞的关键就在于是否能创造一个对象中存在一个指针,指向另一个对象内部,而一般能出现这种情况的对象是String和Array.以前出现的类似漏洞有:CVE-2017-11843

Array Inline Segment 与Array.prototype.splice

在创建数组的时候,如果数组的size小于一定的值,数组的segment是会连着数组的meta data,也就是保存数组数据的segment紧跟数组后面.内存布局如图所示:

let arr = [1.1,2.2,3.3,4.4,5.5,6.6];
Array.isArray(arr);

可以看到0x11c45a07700这个segment的地址是紧跟在array(起始地址0x11c45a076c0)后面,这样的情况称为inline segment.

另一方面Array.prototype.splice这个接口是用来从一个数组删除一定数量的element,然后放到新创建的数组上,具体可以参看MDN

这里chakra在处理splice这个runtime接口的时候,里面存在一个优化的模式,假如要删除的element的start和end刚好等于一个segment的start和end(如上图就是index[0]到[5]),就会把这个segment的地址直接赋值到新创建的数组中(function|ArraySpliceHelper|):

但是这里它需要避免把一个inline segment整个移动到另一个array中,否则就会出现上文提到的那种情况,一个对象中有一个指针指向另一个对象的非开头位置.

而判断是否|hasInlineSegment|的逻辑就是:

检查head segment的length是否少于|INLINE_CHUNK_SIZE|,这里是64.换句话说,现在如果我们要找一个UaF的漏洞,我们需要做的是创建一个head segment的length大于64的array.

JIT PLEASE HELP ME

要想得到这样的一个array是很不容易的,因为在很多创建array的函数中,他们都会检查要创建的大小是否大于64,如果大于64,则会把head segment单独分配在另外一个buffer,不会再紧跟在array后面.

但是,一个chakra引擎是由很多很多人编写的,在我看来,编写JIT模块的人应该与runtime模块的人是不一样的,同样编写JIT的人会比较不熟悉runtime模块上的一些逻辑与细节.而在现实中,很多漏洞往往就是因为不同人员之间协同开发,导致一些跨模块的漏洞出现,这个漏洞就是典型的JIT开发人员不熟悉runtime模块导致.

在今年一月份修复CVE-2018-0776,开发人员引入了这个漏洞: patch和GPZ Report

由于JIT的开发人员不熟悉runtime的逻辑,不清楚在创建数组的时候headsegment的length不能大于64,导致打破了chakra中的一些惯例.我们可以看到|BoxStackInstance|中创建数组的时候,根本没有判断需要创建的head大小就直接创建了一个inline segment array.(这里我们需要deepcopy为true才可以)

所以到底什么是BoxStackInstance,在什么情况下才能调用这个创建数组?

在JIT中,有一个优化机制叫做escape analysis,用于分析一个变量是否逃出了指定的范围,假如一个变量的访问用于只在一个function里面,我们完全可以把这个变量当成局部变量,分配在栈上,在函数返回的时候自动释放.这样的优化可以减少内存的分配和gc需要管理的对象,因为这里对象的生命周期是和函数同步的,并不是由gc管理.

但是这里有一个问题,但是某些特殊情况下,我们需要把这个栈上的变量重新分配到堆上,这时候就需要调用BoxStackInstance重新创建对象.

情况一就是bailout发生的时候,因为需要OSR回到解释器层面执行,这时候就没有所谓的native函数栈概念,只剩下虚拟机的虚拟栈,否则对象会引用已释放的栈空间.这种情况deepcopy为false,并不满足我们的需要.

情况二就是通过arguments访问一个栈变量,因为arguments可能是一个堆对象,它是由gc管理的,它里面必定不能包含栈分配的对象.这时候deepcopy为true.
至此,漏洞的大概原理已经分析清楚.