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

这篇文章将为大家详细讲解有关Office公式编辑器漏洞二代的原理分析、利用与防护方案是怎样的，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

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

漏洞披露后，金睛安全研究团队及时对漏洞相关安全事件进行了跟进。

漏洞影响版本：

Office 365

Microsoft Office 2000      

Microsoft Office 2003      

Microsoft Office 2007 Service Pack 3

Microsoft Office 2010 Service Pack 2

Microsoft Office 2013 Service Pack 1

Microsoft Office 2016

漏洞事件分析：

目前已知的漏洞触发方式存在两种。

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

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

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

漏洞细节分析：

在CVE-2017-11882漏洞的一处修补(0x4164FA)中，修补代码通过增加额外的参数(拷贝字符数)以及增加判断语句、截断语句的方式，修正了所产生的栈溢出。

修补前后的代码如下图所示：

   
   

图 1 – 修补前后的代码对比

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

 

图 2 – 存在漏洞的ReadData函数

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

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

   

图 3 – 对TAG进行解析的函数

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

偏移(以字节为单位)	字段名	说明
-1(已经读入)	TAG	低4位为0101(即5)高4位为可选标志位(optional flags)文档中所提到的“[nudge]if xfLMOVE is set”也在此字段
0	valign	指定对齐方式
1	h_just
2	v_just
3	rows	矩阵的行数和列数对这个数值未进行检验，所以会发生栈溢出
4	cols
5	row_parts	矩阵的行数据和列数据的类型
	col_parts
…	lines	矩阵的行数据和列数据

由于ProcessMatrixRecord(0x443E34)函数对rows和cols两个变量的数值未进行检验，通过real_size = (2 * size + 9) / 8可以计算出实际复制的数据大小。

 通过实际的调试，可以得到栈上的内存布局如下：

EBP – 0x14	row_data
EBP – 0x10
EBP – 0x0C	col_data
EBP – 0x08
EBP – 0x04
EBP
EBP + 0x04	返回地址

 为rows指定0x1C(28)，即实际复制(2 * 28 + 9) / 8 = 8个字节，然后为cols指定一个较大的数值(本例中0x94，即复制38个字节)则会覆盖掉栈上原本的内容。

假定基址为0x400000，首先先用一定的数据覆盖到栈上，结果如下。

   

图 4 – ret时各寄存器的状态

   

图 5 – ret时EAX寄存器所指向的地址

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

   

图 6 – ROP链构造思路

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

中间出现了一个地址值0x455B28。原因要从处理MATRIX记录的函数ProcessMatrixRecord(0x443E34)说起。

 

图 7 – 对MATRIX记录进行解析的函数(ProcessMatrixRecord, 0x443E34)      

在上图的第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机制。

解决方案：

1、下载微软最新补丁

(1) https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-0802

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

2、在注册表中取消该模块的注册

reg add “HKLM/SOFTWARE/Microsoft/Office/Common/COM Compatibility/{0002CE02-0000-0000-C000-000000000046}” /v “Compatibility Flags” /t REG_DWORD /d 0x400

对于在64位操作系统上的32位的Office，执行下列操作

   

reg add “HKLM/SOFTWARE/Wow6432Node/Microsoft/Office/Common/COM Compatibility/{0002CE02-0000-0000-C000-000000000046}” /v “Compatibility Flags” /t REG_DWORD /d 0x400

关于Office公式编辑器漏洞二代的原理分析、利用与防护方案是怎样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。