2019-02-15 08:38

编辑器漏洞_Office公式编辑器漏洞二代的原理分析、利用与防护方案

在上周二(2018年1月9日)的微软例行更新中,微软再一次对Office中的公式编辑器3.0产生的多个内存破坏漏洞进行了修补,并将这一系列漏洞归类于编号CVE-2018-0802。

其中一种由国内安全公司的研究员提出,利用了公式的FONT记录解析漏洞,与之前的CVE-2017-11882漏洞较为接近。目前已经存在此种方式进行利用的在野样本,由于新的利用方式在未打CVE-2017-11882补丁的机器上会造成崩溃,所以需要搭配之前的漏洞利用公式一同使用。

另一种由国外安全公司的研究员提出,使用了公式的MATRIX记录(原报告中误认为是SIZE记录)解析漏洞来造成栈溢出。目前尚未发现利用此种方式的样本。由于此种方式对ASLR机制的绕过需要暴力枚举,会导致打开文档的时间变得极长。

由于前者的报告已经非常详细,且原理与CVE-2017-11882较为接近,本文将主要分析后者。

在CVE-2017-11882漏洞的一处修补(0x4164FA)中,编辑器漏洞_Office公式编辑器漏洞二代的原理分析、利用与防护方案修补代码通过增加额外的参数(拷贝字符数)以及增加判断语句、截断语句的方式,修正了所产生的栈溢出。

但问题正出在这个修补方式上,由于利用类似读入方式的代码有多处,难免存在漏网之鱼。通过对GetByte函数(0×416352)的XREF进行查看,可以查找到另一处可能产生越界拷贝的ReadData函数(0x443F6C)。

实际拷贝的数据大小(real_size)的值经传入的参数(size)计算后得出,但这个传入的参数是在公式中的可控数据。因此将该值更改为较大的值,便会覆盖掉栈上随后的数据。

ReadData函数在0x443E34函数中被调用,继续向上XREF发现仅有0x454F50地址处提到了该函数。向上查看可以发现0x454F30处是一个结构体,通过对这一部分进行逆向可以得到以下内容(参考。

而0x454F30处的结构体对应的是case 4,即MATRIX记录。通过查阅可以发现MATRIX记录的结构如下:

为rows指定0x1C(28),然后为cols指定一个较大的数值(本例中0×94,即复制38个字节)则会覆盖掉栈上原本的内容。

在执行ret语句时,EAX寄存器所指向的地址离样本中可控的输入数据相差0×32个字节。攻击者可以通过构造ROP链,对EAX寄存器的值进行抬高,从而实现执行任意命令。Check Point所给出的思路如下:

大体思路是通过将EAX寄存器的值两次抬高(0×32 / 2 = 0×19),然后使用其值作为WinExec的参数进行调用。

在上图的第26行可以看到对sub_4428F0函数的调用,该调用有对a1(ebp+8)的读写操作(该数据是一个地址),而在ReadData之后,我们所构造的数据已经覆写了这块内存,破坏了原有数据。所以,我们应该至少保证这四个字节的数据是一个可读写的地址。

由于微软在CVE-2017-11882的修补程序中已经强制开启了ASLR机制,所以使exploit奏效仍需绕过此机制。这种方法利用了Word的一个特性:当公式编辑器产生异常时,Word会接管异常并不给出任何提示信息。而EQNEDT32.exe是一个32位进程,编辑器漏洞ASLR空间对应的基址尚且处于可以枚举的范围内——通过构造大量的公式,使用不同的基址构造ROP链即可绕过ASLR机制。

但在Check Point的POC演示视频中可以发现,Word的加载窗口始终没有消失,即Word一直在尝试加载RTF文件,而计算器是在这个过程中被弹出的。笔者自己根据这种方法尝试构造的POC有3MB的大小,触发也需要数分钟的时间,利用此种溢出方式的样本可能需要其他的方式绕过ASLR机制。

(2)开启Windows自动更新。微软最新版本已经去掉了该模块微软将EQNEDT32.EXE从产品中删除,并不再支持旧版本的公式格式。

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: