面向RTF的OLE对象漏洞分析研究

2016-09-22乐德广章亮龚声蓉郑力新吴少刚

网络与信息安全学报 2016年1期

乐德广，章亮，龚声蓉，郑力新，吴少刚

（1.常熟理工学院计算机科学与工程学院，江苏常熟 215500；2.苏州大学计算机科学与技术学院，江苏苏州 215006；3.华侨大学工学院，福建泉州 362021；4.江苏中科梦兰电子科技有限公司，江苏常熟 215500）

面向RTF的OLE对象漏洞分析研究

乐德广1,2,4，章亮3，龚声蓉1,2，郑力新3，吴少刚4

针对RTF文档在OLE对象解析过程中出现的安全漏洞问题，提出了一种基于数据块解析及特征数据构造的OLE对象漏洞分析方法。利用逆向技术分析OLE对象漏洞的触发条件，通过数据块解析定位OLE对象漏洞的触发点，并基于特征数据构造检测OLE对象漏洞。实验表明，该方法不但能正确检测出RTF的OLE对象漏洞，而且能精准定位漏洞触发点，为研究漏洞补丁提供有效依据。此外，与现有方法相比，该方法还具有更高的检测效果，从而有效防御各种面向RTF文档的OLE对象漏洞利用攻击。

RTF文件；软件安全；OLE对象漏洞；漏洞分析

1　引言

随着计算机技术和软件技术的发展，各种办公文档和软件在人们的日常工作和生活中扮演着越来越重要的角色。然而，随着越来越多个人隐私和重要数据通过各种办公软件存储在电子文档中，针对办公软件的攻击事件不断发生，各种办公软件安全问题日趋严重[1]。产生办公软件安全问题的根本原因在于其存在文档格式解析和执行缺陷，即软件安全漏洞[2]。因此，办公软件安全漏洞问题成为信息安全的热门课题，国内外的安全研究机构和学者对办公软件安全漏洞进行了大量的分析研究[3~9]。在文献[3]中，杨丁宁针对微软的MS Office软件在解析DOC、PPT等文档时调用ActiveX控件所产生的漏洞，基于黑盒Fuzzing测试技术设计并实现了 ActiveX 控件漏洞挖掘工具（ActiveX-Fuzzer），并通过该工具发现多个未公布的高危漏洞。刘奇旭在文献[4]中将静态分析和动态测试技术相结合，设计并实现了Flash跨站脚本漏洞挖掘工具（FXD,flash XSS detector），并在对Alexa Top100的网站测试中发现可以导致XSS攻击的Flash文件。Rebert在文献[5]中，根据文件格式结构化存储的特征，给出一种优化种子文件选择的方法，设计并实现一种基于Fuzzing的文件型漏洞智能挖掘与分析系统。在文献[6]中，史飞悦提出了一种动静态分析相结合的漏洞挖掘分析方法对微软Office漏洞进行挖掘分析。文献[7]通过对RTF文件的pFragments绘图属性进行深入研究，提出一种基于指令回溯及特征数据构造的漏洞分析方法分析MS Word程序在RTF文件解析中产生的缓冲区溢出漏洞。该分析方法能有效检测出MS Word的RTF文件绘图属性解析漏洞。此外，Leathery分析了在没有正确处理带有Task Symbol组件的RTF文件时造成堆内存错误而导致触发漏洞[8]。Li分析了MS Office在解析文件时动态调用公共控件而引起的OLE安全漏洞[9]，该类漏洞不仅可以通过DOC或PPT文档触发，甚至通过RTF文件触发。因此，本文在研究RTF文件的OLE对象嵌入技术基础上，提出了一种基于数据块解析及特征数据构造的OLE对象漏洞逆向分析方法，并根据该方法给出了面向RTF文件的OLE对象漏洞分析流程。实验测试证明，本方法能有效检测出RTF文件的OLE对象解析漏洞。此外，与现有的同类检测方法相比，本文方法具有更高的检测效率。

2　研究背景

2.1OLE对象链接和嵌入技术

对象链接和嵌入（OLE，object linking and embedding）是一种面向对象的技术，该技术允许在程序之间链接和嵌入对象数据，从而建立复合文档[10]。微软MS Office 97-2003的各种文件格式（DOC、RTF、XLS和PPT等）都采用OLE技术存储文件规范。通过该规范，一个文件不仅包含文本，而且可以包括图形、电子表格、甚至声音视频信息。这里以一个包含OLE结构的RTF文件为例，新建一个同时包含“Hello World”文本信息和PNG图片的RTF文件，提取出其中的OLE结构，通过Offvis分析其OLE结构[11]，如图1所示。

图1　Offvis分析RTF的OLE文档结构

从图1可以看出，整个OLE结构类似一个容器，称为OLE容器。OLE容器包含了不同的存储目录（directory entry），存储目录中的OLE数据是以流（streams）的形式存储在仓库（storages）中，本例中的文本信息存储在WordDocument流中，图片信息存储在Data流中。

2.2RTF的OLE对象机制

富文本格式（RTF，rich text format）是微软进行文本和图像信息格式交换而制定的一种文件格式[12]。RTF文件可以划分成文件头和文档区两部分，文件头和文档区都由本文、控制字和控制符组成。其中，控制符由一个反斜线跟随单个非字母字符组成。例如，~代表一个不换行空格。控制符不需要分隔符。控制字是RTF用来标记管理文档信息的一种特殊格式的命令，其语法格式为：字母序列<分隔符>。例如， tfN 为RTF的版本号控制字，其中数字N表示主版本号。RTF文件解析程序主要是根据控制字对文件进行解析。表1列出了RTF文件中常用的控制字。

表1　RTF控制字

从表1可以看出，RTF的文件头中包含 tfN、fonttbl、filetbl和listtable等控制字。文档区包含info、pict和object等控制字。其中，object表示OLE对象控制字。通过object控制字，RTF可以像二进制DOC复合文档一样包含图片、电子表格、声音和视频等信息。这些富文本信息在RTF文件中是通过OLE对象类型控制字来解析，表2列出了RTF中不同的OLE对象类型控制字。

在表2中，通过objemb控制字可以嵌入图片、文档、音频信息等，通过objocx控制字可以在OLE容器中包含不同的ActiveX控件，通过objlink控制字可以在不同的应用程序中链接文件。这些对象类型的数据存储在不同的数据区域，表3列出了可存储这些数据的对象数据控制字。

表2　RTF的OLE对象类型

表3　RTF的OLE对象数据

表3中的3个对象数据控制字都可以被对象类型引用，例如OLE嵌入对象类型objemb和OLE控件类型objocx的数据一般存储在objdata控制字中。OLE对象数据包括头部（ObjectHeader）和数据流（ObjectStream），它们是通过D0CF11E0A1B11AE1标志符进行区分，其中头部由OLE版本（4字节）、格式ID（4字节）、程序名长度（4字节）、程序名和数据流大小（4字节）组成。例如，RTF文件中包含OLE控件类型的数据信息如下

{objocx*objdata01050000020000001B0000 004D53436F6D63746C4C69622E4C69737456696 5774374726C2E32000000000000000000000E0000 D0CF11E0A1B11AE100000000000000000000000 0000000003E000300FEFF09000}

在以上objdata控制字的数据信息中，01050000020000001B0000004D53436F6D63746C 4C69622E4C697374566965774374726C2E3200000 0000000000000000E0000为头部信息，D0CF11E 0A1B11AE1为数据流的起始标志信息，000000000000000000000000000000003E000300F EFF09000为数据流信息。

2.3RTF的OLE对象安全性问题

根据2.2节知道RTF文件包含不同的OLE对象类型。由于在解析这些对象类型时需要调用公共控件或动态链接库去解析对象数据。此外，RTF 的OLE对象数据存储在对象数据控制字中，因此objdata等对象数据控制字属于可存数据区域。在这些可存数据区域中，可以构造溢出数据，甚至恶意代码（Shellcode等）。当OLE对象在解析这些特殊构造的数据时，将触发OLE对象漏洞，并利用该漏洞执行恶意代码，从而产生RTF文件攻击。因此，在RTF文件中包含OLE对象引发安全漏洞，称为RTF的OLE对象漏洞。例如，当在RTF文件中嵌入objocx对象类型的OLE控件TreeView或ListView时，该控件在解析objdata内部数据时会造成堆栈溢出漏洞，利用该漏洞能进行远程代码执行攻击[13]。当RTF文件在解析嵌入objocx对象类型的OLE控件TabStrip时会造成内存破坏漏洞[14]。在RTF文件中包含objemb对象类型的TIFF数据时，会由于OGL.DLL在处理TIFF文件格式数据时产生整数溢出导致堆溢出漏洞[15]。此外，在RTF漏洞利用攻击过程中，通常会利用OLE对象绕过Windows的安全防护机制[16]。例如，在漏洞利用的时候经常需要绕过Windows的地址空间布局随机化（ASLR，address space layout randomization）机制，这时可以在RTF文件OLE对象的objdata数据区域中包含未开启ASLR机制的控件（MSCOMCTL.OCX，MSGR3EN.DLL等），通过这种方式可以绕过ASLR[17]。

由于 RTF文件经常会伴随着嵌入的OLE对象漏洞进行攻击，因此本文重点分析RTF的OLE对象漏洞。目前，已有一些国外的信息安全专家对RTF的OLE对象安全性问题开展相关研究，如Boldewin设计和实现了一种用于分析和提取RTF中恶意嵌入OLE对象的工具RTFscan[18]；Bonfa提出了一种基于OLE数据结构分析的方法，并设计和实现了用于检查并解密RTF样本恶意代码的OLE漏洞扫描工具pyOLEscanner[19]。这些方法和工具虽然可以判断RTF文件中是否包含存在漏洞的OLE对象或Shellcode，但是并不能准确定位漏洞的触发点。本文在此基础上，通过逆向分析技术分析RTF文件中的OLE对象嵌入机制，并提出一种基于数据块解析及特征数据构造的OLE对象漏洞分析方法。

3　面向RTF文件的OLE对象漏洞分析

3.1RTF的OLE对象类型逆向分析

通过一个包含OLE对象类型的RTF文件（test.rtf）对OLE对象嵌入机制进行逆向分析，其关键数据信息如下

{objectobjocxf37objsetsizeobjw1500objh7 49{*objclass MSComctlLib.ListViewCtrl.2}

{*objdata01050000020000001B0000004D53 436F6D63746C4C69622E4C697374566965774374 726C2E32000000000000000000000E0000D0CF11 E0A1B11AE1000000000000000000000000000000 003E000300FEFF090006000000000000000000000 001000000010000000000000000100000020000000 1000000FEFFFFFF0000000000000000FFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF F……52006F006F007400200045006E0074007200 7900000000000000000000000000001EFCDAB00 00050000000000060000000800008005000080B03 03A0300000000000000000000000016000500FFFF FFFFFFFFFFFF020000004BF0D1BD8B85D111B1 6A00C0F02836280000000062BCDFB9340DCD……2143341208000000746174696F6E00134E087D EB010006001C00000000000000000000000006000 1560A000001EFCDAB00000500985D6501070000 000800008005000080000000000000000000000000 000000001FDEECBD010005009017190000000800 000049746D736400000002000000010000000C000 000436F626A640000000800000008000000E53746 C4C69622E4……}}

在以上RTF文件数据中，object控制字表示解析的是一个OLE对象类型；objocx控制字表示该对象类型为OLE控件类型；objclass控制字引用MSComctlLib.ListViewCtrl.2参数，该参数表示 OLE对象类型调用 MSComctlLib中的ListViewCtrl.2控件；objdata控制字表示对象数据，这些对象数据采用十六进制形式存储。将objdata控制字对象数据的头部信息通过Winhex进行解析[20]，如图2所示。

从图2可以看出，根据OLE对象数据的头部组成，OLE版本的值为0x00000501；格式ID的值为0x00000002，表示OLE对象嵌入在RTF文件中；程序名长度的值为0x0000001B，表示程序名的长度为27字节；程序名为MSComctlLib.ListViewCtrl.2，数据流大小的值为0x00000E00，表示数据流信息的大小是3 584字节。

下面通过 Windbg对 MSComctlLib.List-ViewCtrl.2指定的ListViewCtrl.2控件进行逆向调试[21]，发现RTF在解析该ObjectStream数据时，是将数据读取到栈空间中，如图3(a)所示。例如，读取OLE对象中ObjectStream的01EFCDAB 0000050000000000060000000800008005000080B 0303A03数据的关键代码，如图3(b)所示。

从图3(b)可以看到在解析ObjectStream数据时，通过rep movs dword ptr es:[edi],dword ptr[esi]指令，将文档中数据读取至栈（如图3(a)所示）中。这种串复制指令很容易造成堆栈溢出或内存破坏，因此RTF在解析包含OLE对象的文档时可能存在OLE对象漏洞。

3.2基于数据块解析和特征数据构造的OLE对象漏洞分析

根据3.1节对RTF文件中的OLE对象类型分析，知道当RTF中包含OLE对象，并在解析ObjectStream时可能会产生OLE对象漏洞，本小节在此基础上进行基于数据块解析的OLE对象漏洞分析。分析调试工具为Windbg[21]，RTF分析文档为3.1小节中的test.rtf，RTF文件解析程序为MS Word 2010。

RTF文件中的 OLE对象数据保存在ObjectStream中，而ObjectStream内部数据按照属性进行分类，具有相同属性的数据属于同一个数据块，例如OCXNAME数据块、Table数据块，Contents数据块等，因此ObjectStream中一般存在多个数据块。RTF文件解析程序通过类标识符（CLSID，class identifier）指定解析ObjectStream数据块时调用的控件类型。分析发现在函数OLE32.ReadClassStg中读取 OLE对象中的CLSID

BDD1F04B-858B-11D1-B16A-00-C0F0283628，该控件位于MSCOMCTL.OCX中。通过Windbg在解析该数据块入口的位置处下断点，确定解析该数据块的部分关键代码如图4所示。

图2　OLE对象数据的头部信息

图3　RTF解析ObjectStream关键代码

在图4中，地址0x276008F1处调用的函数为OLE32.CExposedDocFile::openstream。该函数的作用是打开一个Stream流，通过其中一个参数[275E56A0]=Contents知道该处打开的是一个内容为Contents的Stream流，因此这里实际上要解析的是OLE对象中的Contents数据块。解析Contents数据块前8个字节的关键代码如图5所示。

图4　解析OLE对象数据部分关键代码

在图5中，地址0x2758AF04处调用的函数为OLE32.CExposedStream::Read，该函数的作用是读入Stream流，其中第2个参数为要读入数据返回的buffer，第3个参数为要读入数据的大小。在这里buffer的地址为0x001278E4，是一个栈空间的地址，读取的数据大小为0x08字节，因此通过OLE32.CExposedStream::Read将Contents数据块的前8个字节读入栈空间。读完后，在地址0x2758AF08和0x2758AF18处分别对读入的数据进行校验，校验是否为固定数据0x12344321和0x08。如果校验成功，则继续读取Contents数据块余下的数据。如果校验失败，则退出该数据块校验进程。Contents数据块其他数据的读取方式也是将数据读取至栈区，再对数据进行校验，其读取校验过程如图6所示。

从图6可以看出，在读取数据块中的数据时不是一次性读完，而是读取其中一部分数据，边读边校验。只有当校验通过时才会继续读取数据直至数据读取完毕，否则剩余数据也不会再读取。根据图6的流程，最终读取的数据如下

2143341208000000746174696f6e00134E087 DEB010006001C000000000000000000000000060 001560A000001EFCDAB00000500985D65010700 000008000080050000800000000000000000000000 00000000001FDEECBD0100050090171900000008 00000049746D736400000002000000010000000C0 00000436F626A640000000800000008000000E537 46C4C69622E4

图5　解析Contents数据块部分关键代码

在以上数据中，当读取校验Contents数据块尾部中的0C000000436F626A6400000008000000 E53746C4C69622E4数据时，读入该部分数据的关键解析代码如图7所示。

从图7可以看出，在地址0x275C89CA处，通过sub esp,14h指令开辟0x14大小的空间用于存储 Contents数据块尾部数据，并在地址0x275C89DA处第1次调用函数MSCOMCTL.GetClassObject，该函数读入数据关键代码如图8所示。

图6　Contents数据块的读取校验流程

从图8可以看出，在地址0x275C8783处，通过 call dword ptr[eax+0Ch]调用 OLE32.CExposedStream::Read函数，从Contents数据块尾部读取1~4字节的数据至栈区。随后在地址0x275C878D处，cmp dword ptr[ebp-4],edi指令校验读入的数据是否和0x0C相等（参见图7地址0x275c89d3处的push 0Ch）。如果不相等，则不读取数据；如果相等，则从数据块中读取0x0C字节数据至栈区，并且对读取数据中的前4个字节是否为0x6A626F43进行校验。如果校验不成功，则退出当前数据块的解析；如果检验成功，则判断所读取的0x0C字节数据中的后4个字节是否大于或等于0x08（参见图7地址0x275c89f3处的cmp dword ptr[ebp-0Ch],8指令）。如果小于0x08，则不读取数据，并退出当前数据块的解析；如果大于或等于 0x08，则继续调用函数MSCOMCTL.GetClassObject从数据块中取4个字节的数据至栈区。根据图8地址0x275C878D处的cmp dword ptr[ebp-4],edi指令，校验读入栈区的数据是否和[ebp-0Ch]相等（参见图7地址0x275c89fd处的push dword ptr[ebp-0Ch]指令）。如果不相等，则不读取数据，并退出当前数据块的解析；如果相等，则从数据块中读取[ebp-0Ch]字节数据至栈区。

图7　解析Contents数据块尾部数据关键代码

图8　MSCOMCTL.GetClassObject部分关键代码

根据以上分析发现，程序刚开始只开辟了0x14大小的栈空间，第1次读取了0x0C字节数据至该区域。如果该区域中的最后4个字节大于或等于0x08，那么程序会继续读取数据至栈区。如果在接下来调用MSCOMCTL.GetClassObject时，数据校验成功，就会读入超过0x08个字节数据至栈区，从而造成栈溢出。

3.3RTF的OLE对象漏洞分析流程

根据3.2节对OLE对象漏洞的分析，得到RTF中的OLE对象漏洞分析流程，如图9所示。

图9　RTF的OLE对象漏洞分析流程

从图9可以看出，在解析RTF文件时，首先确定包含的OLE对象类型，并将对象数据读至缓冲区中；接着校验对象数据，并对读取校验成功数据的代码进行分析；最后根据代码执行流程，在数据块中相应位置构造特征数据，并判断是否会造成溢出。如果不溢出，则读取接下来的数据；如果溢出，则定位漏洞。

4　测试结果与分析

本节将对3.3节提出的OLE对象漏洞分析流程进行实验测试，实验环境为Intel(R)Core(TM)i5-3230M CPU、4 GB内存、OS为Microsoft Windows 7 SP1。首先，通过一个实例测试本方法的正确性；然后，针对不同OLE对象的漏洞进行测试，并与现有工具进行比较，证明本方法具有更高的检测效率；最后，通过构造畸形测试用例来测试本方法的抗干扰性。

4.1实例测试

根据3.3节的分析流程，OLE对象数据是能否触发漏洞的关键，只有在OLE对象类型中构造合适的对象数据才能造成缓冲区溢出，触发漏洞。在RTF的objocx对象类型中，首先通过3.2节对objdata对象数据的Contents数据块尾部分析，发现由Contents数据块尾部的第1至第4字节所构成的8位16进制数等于0x0C，且第5至第8字节的 8位 16进制等于 0x6A626F43时，即(4321)H=0x0C，(8765)H=0x6A626F43，才能将指定大小的数据复制到缓冲区中。该复制数据的大小由Contents数据块尾部的第1至第4字节构成的二进制数决定，即(4321)H。根据图9中的数据读入和数据校验判断条件构造Contents数据块尾部第1至第8字节的特征数据为0C000000436F626A，这样可以使得第1次校验成功，而且会第2次调用MSCOMCTL.GetClassObject（参见图8）。

接着，根据图9中的数据溢出判断条件，通过特征数据构造方法，将objdata对象数据的Contents数据块尾部第9至第20字节的数据构造成 640000008800000088000000。最后，根据Contents数据块尾部第9至第20字节构造的数据在Contents数据块尾部的剩余数据中构造0x88大小的特征数据aaaa…。这样，在第2次的MSCOMCTL.GetClassObject函数调用中，地址0x275C879E处调用Kernel32.HeapAlloc函数（参见图8）开辟一段大小0x88字节堆空间，在地址0x275C87B5处调用函数OLE32.CExposedStream:: Read（参见图8）继续从数据块中读取大小为0x88字节数据至分配的堆空间中。最后，在地址0x275C87CB处调用指令 rep movs dword ptr es:[edi],dword ptr ds:[esi]（参见图8）将这些数据读取至栈区，如图10所示。

图10　栈溢出

从图10可以看出，在数据块中构造的数据aaaa…成功读入栈区，并且造成溢出。通过这个实例证明了本文分析方法的正确性。

4.2与其他工具比较测试

下面通过Windbg的脚本调试功能，创建一个模拟Word 2010解析RTF中OLE对象漏洞流程的脚本文件。然后，通过Windbg对不同的漏洞样本进行测试，并与现有的RTFScan[18]和pyOLEscanner[19]工具进行比较。这里选择10个Word漏洞进行测试，包括最常攻击利用的漏洞（CVE-2010-3333、CVE-2012-0158、CVE-2012-1856、 CVE-2013-3906、 CVE-2014-1761和CVE-2014-6357）以及2015年新发现的OLE对象漏洞（CVE-2015-1770、CVE-2015-2424、CVE-2015-1641和CVE-2015-2369）。为了更好地对比3种不同的检测方法，对每个CVE编号的漏洞通过构造不同特征数据、变换Shellcode及其加密方式，并添加额外正常OLE控件等规则生成20个测试样本（总共200个测试样本），表4记录了采用不同的方法检测到的样本数量。

表4　本文方法与其他工具的测试结果对比

CVE-2015-1770　0　12　14 CVE-2015-2424　0　0　12 CVE-2015-2369　0　0　11 CVE-2015-1641　2　13　17

从表4可以看出，对于CVE-2012-0158、CVE-2012-1856、CVE-2013-3906、CVE-2014-6357、CVE-2015-1770、CVE-2015-2424、CVE-2015-2369 和CVE-2015-1641，本文方法的检测效果明显优于其他两种方法，由于这8个漏洞都是典型的OLE对象漏洞，根据3.3节，通过找到控件标识符CLSID，随后加载控件调用指定的控件解析对应数据块，而这8个漏洞的CLSID和控件都可以定位到，接着在读取数据至缓冲区时进行代码分析，并通过样本中的特征数据测试定位到漏洞。对于CVE-2010-3333和CVE-2014-1761，本文方法没有检测出异常样本，经分析发现这两个漏洞分别是RTF绘图属性缓冲区溢出漏洞和RTF数组溢出漏洞，所以本文方法检测不到该样本。此外，对本文方法未检测出的其他漏洞样本分析发现，主要是由于对象类型叠加或构造的特征数据未造成溢出，从而检测不到异常。pyOLEscanner的检测效率优于RTFScan，这是由于pyOLEscanner可以检测文档中是否还有宏和ActiveX等控件。例如，通过对OLE对象数据结构进行分析，发现在解析CVE-2015-1770漏洞样本数据时，加载了ActiveX控件OSF.DLL，而pyOLEscanner存在OSF.DLL的解析模块，因此可以检测到该漏洞。RTFScan相比其他两种方法，其检测效率最差，能够检测到的各个漏洞测试样本数量有限，主要原因是RTFScan靠检测文档中的Shellcode，随着Shellcode以及加密技术的发展，文档中的Shellcode越来越难以通过特征匹配的方式定位，因此对于比较复杂的漏洞样本文件，RTFscan几乎很难检测到。

4.3抗干扰性测试

RTF解析程序不但可以正确地解释基于文献[12]语法规范生成的RTF文件，而且能够忽略它不知道或者未使用的控制字，并且能正确地略过被*控制符标记的部分。因此，RTF文件中往往存在没有完全符合语法规范的数据格式。在实际的漏洞样本中，为了躲避检测，经常会在样本中插入一些无意义的数据干扰漏洞检测。由于本文提出的方法需要对object、objocx、OLE起始标志位以及CLSID进行分析，因此本测试采用网络上公开的300例测试用例对本文方法的抗干扰性进行测试[22]。在这300例测试用例中，分别对object和objocx采用空格等字符进行混淆，对OLE起始标志位和CLSID采用转义字符进行混淆，表5分别列出了不同字段未检测到的测试用例数目。

表5　抗干扰测试结果

在表5中可以看出，在300例的测试样本中，总共有84例漏洞样本未检测出，其中object控制字35例，objdata控制字24例，OLE起始标志位10例，CLSID 15例。通过对测试样本的数据分析发现，object和objocx的混淆影响检测结果最严重。当样本中添加空格混淆，例如在样本中控制字可以表现为object等类似变形的字符串时，由于本文解析包含OLE对象的RTF文件时，是通过查找标记为object与objocx的字符串来确定包含的OLE对象类型，因此对检测效果影响较大。CLSID和OLE起始标志位由数据串组成，可以采用 d0 0cf11e0a1b11ae1或者“in”等转义字符进行混淆。通过对测试样本的数据分析发现，采用转义字符方式混淆的样本数量不多。因此，CLSID和OLE起始标志位混淆对检测效果影响较小。

5　结束语

软件安全漏洞的分析已经成为了当今国内外信息安全研究的热点，如何解决文档型办公软件的安全漏洞问题也成为安全研究人员的重点研究课题，现有一些学者在分析Flash、PDF、DOC文件漏洞方面取得了很大的进展，但对于RTF文件中的OLE对象漏洞这一问题，尚未提出较好的方法。本文分析了RTF的OLE对象机制及其安全问题，针对在解析RTF文件的OLE对象属性时会产生的安全漏洞进行分析，并给出了OLE对象漏洞一般分析方法，最后通过实验测试证明了该方法的有效性。

通过测试发现本文的方法在针对混淆样本的检测中，漏检率较高，但其抗干扰性方面还需要进一步提高。此外，由于本文在数据块解析过程中采用逆向分析，而逆向分析的过程往往是通过手工或脚本方式实现，这样会降低分析的效率，因此在下一步的工作中，重点研究如何自动化实现逆向分析。

[1]NAGARAJU S S,CRAIOVEANU C,FLORIO E,et al.Software vulnerabilityexploitation trends[R].2013.

[2]吴世忠,郭涛,董国伟,等.软件漏洞分析技术进展[J].清华大学学报（自然科学版）,2012,52(10):1309-1319.WU S Z,GUO T,DONG G W,et al.Software vulnerability analysis:a road map[J].Journal of Tsinghua University(Science and Technology),2012,52(10):1309-1319.

[3]杨丁宁,肖晖,张玉清,等.基于fuzzing的ActiveX控件漏洞挖掘技术研究[J].计算机研究与发展,2012,49(7):1525-1532.YANG D N,XIAO H,ZHANG Y Q,et al.Vulnerability detection in ActiveX controls based on Fuzzing technology[J].Journal of Computer Research and Development,2012,49(7):1525-1532.

[4]刘奇旭,温涛,闻观行,等.Flash跨站脚本漏洞挖掘技术研究[J].计算机研究与发展,2014,51(7):1624-1632.LIU Q X,WEN T,WEN G X,et al.Detection of XSS vulnerabilities in online flash[J].Journal of Computer Research and Development,c2014,51(7):1624-1632.

[5]REBERT A,CHA S K,AVGERINOS T,et al.Optimizing seed selection for Fuzzing[C]//The 23rd USENIX Security Symposium, San Diego.2014:861-875.

[6]史飞悦,傅德胜.缓冲区溢出漏洞挖掘分析及利用的研究[J].计算机科学,2013,40(11):143-146.SHI F Y,FU D S.Research of buffer overflow vulnerability discovering analysis and exploiting[J].Computer Science,2013, 40(11):143-146.

[7]乐德广,章亮,郑力新,等.面向RTF文件的Word漏洞分析[J].华侨大学学报（自然科学版）,2015,36(1):17-22.LE D G,ZHANG L,ZHENG L X,et al.Research on word vulnerability analysis for the RTF file[J].Journal of Huaqiao University(Natural Science),2015,36(1):17-22.

[8]LEATHERY J.Microsoft office zero day CVE-2015-2424[EB/OL].http://www.isightpartners.com/2015/07/microsoft-office-zero-daycve-2015-2424-leveraged-by-tsar-team/.

[9]LI H F,SUN B.Attacking interoperability:an OLE edition [EB/OL].https://www.blackhat.com/docs/us-15/materials/us-15-Li-Attacking-Interoperability-An-OLE-Edition.pdf.

[10]MICROSOFT.OLE concepts and requirements overview[EB/OL].https://support.microsoft.com/en-us/kb/86008.

[11]MICROSOFT.The microsoft office visualization tool(OffVis) [EB/OL].http://www.microsoft.com/en-us/download/details.aspx?id =2096.

[12]MICROSOFT.Rich text format(RTF)specification version 1.9.1 [S].2008.

[13]MICROSOFT.MicrosoftsecuritybulletinMS12-060[EB/OL].https://technet.microsoft.com/en-us/library/security/ms12-060.

[14]MICROSOFT.MicrosoftsecuritybulletinMS12-027[EB/OL].https://technet.microsoft.com/en-us/library/security/ms12-027.aspx.

[15]MICROSOFT.Microsoft security bulletin MS13-096[EB/OL].https:// technet.microsoft.com/en-us/library/security/ms13-096.aspx.

[16]王明华,应凌云,冯登国.基于异常控制流识别的漏洞利用攻击检测方法[J].通信学报,2014,35(9):20-31.WANG M H,YING LY,FENG D G.Exploit detection based on illegal control flow transfers identification[J].Journal on Communications, 2014,35(9):20-31.

[17]HUND R,WILLENS C,HOLZ T.Practical timing side channel attacks against kernel space ASLR[C]//IEEE Symposium on Security and Privacy(SP).Berkeley,c2013:191-205.

[18]BOLDEWIN F.OfficeMalScanner/RTFScan[EB/OL].http://www.reconstructer.org/.

[19]BONFA G E.PyOLEScanner[EB/OL].http://www.aldeid.com/wiki/ PyOLEScanner.

[20]X-WAYS AG.WinHex hex editor[EB/OL].http://www.winhex.com/ winhex/hex-editor.html.

[21]MICROSOFT.Debugging tools for windows[EB/OL].https://msdn.microsoft.com/en-us/library/ff551063.aspx.

[22]PARKOUR M.Malicious files for signature testing and research [EB/OL].http://contagiodump.blogspot.de/2013/03/16800-clean-and-11960-malicious-files.html.

Research on OLE object vulnerability analysis for RTF file

LE De-guang1,2,4,ZHANG Liang3,GONG Sheng-rong1,2,ZHENG Li-xin3,WU Shao-gang4

(1.School of Computer Science and Engineering,Changshu Institute of Technology,Changshu 215500,China; 2.School of Computer Science and Technology,Soochow University,Suzhou 215006,China; 3.College of Engineering,Huaqiao University,Quanzhou 362021,China; 4.Jiangsu Lemote Technology,Changshu 215500,China)

In order to deal with the problem of OLE parsing vulnerability for RTF documents,a kind of vulnerability analysis method based on data block analysis and characterization data construction was proposed.The trigger conditions of OLE object vulnerability by reverse engineering technique were analyzed.The trigger point of vulnerability was located through data block analysis.The OLE object vulnerability was detected based on characterization data construction.Tests show that the proposed method not only detects the OLE object vulnerability correctly,but also locates the point of vulnerability accurately,which provides the effective support for the research on vulnerability patches.Besides,the detection effectiveness of the proposed method is higher than that of other methods,which can effectively defense the exploit attack of OLE object vulnerability for RTF documents.

RTF document,software security,OLE vulnerability,vulnerability analysis

TP393

10.11959/j.issn.2096-109x.2016.00011

2015-10-25；

2015-11-19。通信作者：乐德广，306045675@qq.com

国家自然科学基金资助项目（No.61202440,No.61170124,No.61402057）；福建省物联网云计算平台建设基金资助项目（No.2013H2002）

Foundation Items:The National Natural Science Foundation of China(No.61202440,No.61170124,No.61402057),Fujian Internet of Things and Cloud Computing Program(No.2013H2002)