IE 11存在Double-Free漏洞导致远程代码执行(CVE-2018-8460)

阅读量    57398 | 评论 1   稿费 200

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

 

概述

在刚刚过去的微软补丁日,微软发布了Internet Explorer(IE)的更新,以解决CVE-2018-8460漏洞。该漏洞影响所有Windows版本中的IE 11,属于微软描述的通用“内存损坏”类别漏洞,但实际上是源于CSS机制的Double-Free漏洞,最终导致允许远程代码执行。这一漏洞非常典型,值得我们进行深入分析。

微软漏洞通告请参见: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8460

 

漏洞详情

该漏洞存在于处理程序对属性cssText写入的代码中。这一DOM属性允许开发人员获取或设置CSS属性字符串,在单次操作中检索或替换样式对象的全部内容。
在为DOM中元素样式设置cssText属性期间,IE将根据需要,触发DOMAttributeModified事件。如果攻击者对DOMAttributeModified事件进行操作,并将其用于重新输入cssText属性设置时,将会出现问题。具体来说,该机制中没有考虑在执行过程中可能发生的情况,如果在此期间重新进入,将会对样式对象的内容进行额外的更改。在实际中,当cssText的(外部)调用完成后,元素的CStyleAttrArray处于损坏状态,其中的两个元素包含指向内存中相同CSS值字符串的指针:

CStyleAttrArray中的字符串指针复制过程,实际上不应该发生。最终,当这个CStyleAttrArray被销毁时,析构函数将会在每个指针上调用HeapFree。由于列表中有一个重复的指针,因此HeapFree将使用这个指针调用该值两次,就形成了Double-Free漏洞。需要注意的是,由于分配是在Windows进程堆上进行的,因此MemGC就不再适用。

以下是触发Double-Free漏洞的PoC:

https://www.thezdi.com/s/CVE-2018-8460-PoC-s34g.txt

 

实现漏洞利用

要实现Double-Free类型的漏洞利用,实际上特别具有挑战性。到目前为止,Windows堆管理器已经经过加固,可以自动检测到HeapFree的参数是已经释放的堆块,并且会立即关闭进程,从而防止进一步损坏。

然而,实际上,确实存在Double-Free类型漏洞的利用方法。如果我们有办法,在第一次HeapFree发生和第二次HeapFree发生之间的时间里,在该地址引起一次新的分配,就可以完全绕过上述缓解措施。

在这种情况下,第二次HeapFree发生时,堆管理器会将相应的块视为已经分配的内存,而不是已释放的内存。因此,就不会发现这一过程存在任何问题,然后将继续释放分配(第二次),从而进一步产生可以实现漏洞利用的条件。

为了实现上述操作,我们采取如下措施:

1、触发第一次HeapFree,释放位于地址A的对象X。

2、引起一次新的分配,新对象Y将位于地址A的位置。实际上,可能需要喷射(Spray)许多对象,才能确保其中有一个对象是在地址A的位置。

3、触发第二次HeapFree,由于此时Y位于A位置,所以将会释放对象Y。

4、引起一次新的分配,新对象Z是位于地址A的第三个对象。和上面一样,可能需要进行喷射(Spray)。

5、使用对象Y的触发代码。该代码将会对对象Z进行操作,而对象Z目前位于地址A的位置。这样一来,我们就可以利用这一漏洞。

如果能够实现上述步骤,所造成的结果是非常具有破坏性的,因为攻击者可以任意控制对象Y和对象Z的类型。攻击者很可能利用这一方式,进行信息获取或控制流劫持,从而导致完整的远程代码执行,无需与其他任何漏洞组合使用。

但是,反观上述步骤,我们发现其中的步骤2最难实现。在实际中,如何能保证步骤2成功呢?我们首先来看看CAttrArray::Free中的代码,其中发生了两次释放:

简而言之,我们有一个循环。在每次循环期间,都会将数据从第一个数组元素复制到临时结构(v13)中,调用memmove将其余元素向下移动一个位置(数组元素1,经过移动后就是数组元素0,以此类推),然后在已删除的数组元素中找到的指针上调用ProcessHeapFree。照此循环,直至数组为空。实际上,循环中还包含一些其他代码(此处未体现),这些代码是为了响应其他类型的数组元素而执行的。根据推测,由于其他代码具有较高的复杂性,因此必须要使用这种低效的O(n^2)算法来清除数组。

由于包含重复指针的两个数组元素在数组中彼此相邻,因此在对ProcessHeapFree的两次调用之间执行的代码非常少。那么,我们如何能保证在两次释放之间产生分配呢?

请注意,在对ProcessHeapFree的连续调用之间,将会调用memmove。假设我们可以将这个memmove变成一个耗时较长的操作,就会在两次对ProcessHeapFree的调用之间赢得时间延迟。如果我们使用第二个执行线程,在第一个线程清除数组的同时快速连续调用HeapAlloc,那么就可以赢得竞态条件(Race Condition),并在两次ProcessHeapFree调用之间执行所需的分配。

只有当攻击者能够控制memmove的长度,使该长度变得非常大时,这种方法才可行。当我进一步研究这一特定漏洞时,所获得的结果令我感到非常惊讶。要增加memmove的大小,只需要向元素中添加额外的自定义样式属性,这样一来,CStyleAttrArray的大小将会增加。举例来说,攻击者可以添加名为-ms-xyz1、-ms-xyz2之类的样式。这一点,已经在上面的PoC中有所说明。此外,我还发现了IE中存在对样式属性数量的限制,最多只能有100万个样式。由于每个属性在CStyleAttrArray中由16字节元素表示,因此我们最多也只能将memmove扩大到16MB,但这并不足以产生足够的时间延迟。实际上,我们可以通过一些额外的技巧来实现漏洞利用,例如:使用大量的分配线程,提高赢得竞态条件的几率。总而言之,这种技术在理论上可行,但在具体实践过程中能够可靠利用,还有待观察。

在这种情况下,攻击者可以寻找一种修改PoC的方式,使CStyleAttrArray中的重复指针不再位于相邻的元素中,从而提高成功几率。这样一来,在两次调用ProcessHeapFree之间,就有更多的代码被执行,也就赢得了更长的时间。当然,将产生回调的代码添加到脚本中是最理想的方案,这样我们就能轻松执行分配,无需再进行竞态。

 

总结

可能大家还会发现,这一漏洞针对服务器是“中危”,但针对客户端是“高危”。其原因在于,IE默认在服务器上开启了增强安全配置(Enhanced Security Configuration,ESC)。如果服务器上禁用了此功能,那么漏洞级别也应该相应提升。微软在“漏洞利用指数”中,给这个漏洞评了1,这意味着在接下来的一个月中,可能会出现对该漏洞的实际利用。该漏洞由ca0nguyen提交给ZDI(ZDI-18-1137)。在对这个漏洞的研究过程中,我发现IE存在一个OOB写入漏洞,这可能是微软之所以将该漏洞归类于“内存损坏”的原因。这两个漏洞都是通过CVE-2018-8460实现的修复,因此需要提醒用户,务必及时更新补丁。

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多