面向RTF的OLE對(duì)象漏洞分析研究

樂德廣，章亮，龔聲蓉，鄭力新，吳少剛

（1.常熟理工學(xué)院計(jì)算機(jī)科學(xué)與工程學(xué)院，江蘇 常熟 215500；2.蘇州大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，江蘇 蘇州 215006；3.華僑大學(xué)工學(xué)院，福建 泉州 362021；4.江蘇中科夢(mèng)蘭電子科技有限公司，江蘇 常熟 215500）

面向RTF的OLE對(duì)象漏洞分析研究

樂德廣1,2,4，章亮3，龔聲蓉1,2，鄭力新3，吳少剛4

（1.常熟理工學(xué)院計(jì)算機(jī)科學(xué)與工程學(xué)院，江蘇 常熟 215500；2.蘇州大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，江蘇 蘇州 215006；3.華僑大學(xué)工學(xué)院，福建 泉州 362021；4.江蘇中科夢(mèng)蘭電子科技有限公司，江蘇 常熟 215500）

針對(duì)RTF文檔在OLE對(duì)象解析過程中出現(xiàn)的安全漏洞問題，提出了一種基于數(shù)據(jù)塊解析及特征數(shù)據(jù)構(gòu)造的OLE對(duì)象漏洞分析方法。利用逆向技術(shù)分析OLE對(duì)象漏洞的觸發(fā)條件，通過數(shù)據(jù)塊解析定位OLE對(duì)象漏洞的觸發(fā)點(diǎn)，并基于特征數(shù)據(jù)構(gòu)造檢測(cè)OLE對(duì)象漏洞。實(shí)驗(yàn)表明，該方法不但能正確檢測(cè)出RTF的OLE對(duì)象漏洞，而且能精準(zhǔn)定位漏洞觸發(fā)點(diǎn)，為研究漏洞補(bǔ)丁提供有效依據(jù)。此外，與現(xiàn)有方法相比，該方法還具有更高的檢測(cè)效果，從而有效防御各種面向RTF文檔的OLE對(duì)象漏洞利用攻擊。

RTF文件；軟件安全；OLE對(duì)象漏洞；漏洞分析

1　引言

隨著計(jì)算機(jī)技術(shù)和軟件技術(shù)的發(fā)展，各種辦公文檔和軟件在人們的日常工作和生活中扮演著越來越重要的角色。然而，隨著越來越多個(gè)人隱私和重要數(shù)據(jù)通過各種辦公軟件存儲(chǔ)在電子文檔中，針對(duì)辦公軟件的攻擊事件不斷發(fā)生，各種辦公軟件安全問題日趨嚴(yán)重[1]。產(chǎn)生辦公軟件安全問題的根本原因在于其存在文檔格式解析和執(zhí)行缺陷，即軟件安全漏洞[2]。因此，辦公軟件安全漏洞問題成為信息安全的熱門課題，國內(nèi)外的安全研究機(jī)構(gòu)和學(xué)者對(duì)辦公軟件安全漏洞進(jìn)行了大量的分析研究[3~9]。在文獻(xiàn)[3]中，楊丁寧針對(duì)微軟的MS Office軟件在解析DOC、PPT等文檔時(shí)調(diào)用ActiveX控件所產(chǎn)生的漏洞，基于黑盒Fuzzing測(cè)試技術(shù)設(shè)計(jì)并實(shí)現(xiàn)了 ActiveX 控 件 漏 洞 挖 掘 工 具（ActiveX-Fuzzer），并通過該工具發(fā)現(xiàn)多個(gè)未公布的高危漏洞。劉奇旭在文獻(xiàn)[4]中將靜態(tài)分析和動(dòng)態(tài)測(cè)試技術(shù)相結(jié)合，設(shè)計(jì)并實(shí)現(xiàn)了Flash跨站腳本漏洞挖掘工具（FXD,flash XSS detector），并在對(duì)Alexa Top100的網(wǎng)站測(cè)試中發(fā)現(xiàn)可以導(dǎo)致XSS攻擊的Flash文件。Rebert在文獻(xiàn)[5]中，根據(jù)文件格式結(jié)構(gòu)化存儲(chǔ)的特征，給出一種優(yōu)化種子文件選擇的方法，設(shè)計(jì)并實(shí)現(xiàn)一種基于Fuzzing的文件型漏洞智能挖掘與分析系統(tǒng)。在文獻(xiàn)[6]中，史飛悅提出了一種動(dòng)靜態(tài)分析相結(jié)合的漏洞挖掘分析方法對(duì)微軟Office漏洞進(jìn)行挖掘分析。文獻(xiàn)[7]通過對(duì)RTF文件的pFragments繪圖屬性進(jìn)行深入研究，提出一種基于指令回溯及特征數(shù)據(jù)構(gòu)造的漏洞分析方法分析MS Word程序在RTF文件解析中產(chǎn)生的緩沖區(qū)溢出漏洞。該分析方法能有效檢測(cè)出MS Word的RTF文件繪圖屬性解析漏洞。此外，Leathery分析了在沒有正確處理帶有Task Symbol組件的RTF文件時(shí)造成堆內(nèi)存錯(cuò)誤而導(dǎo)致觸發(fā)漏洞[8]。Li分析了MS Office在解析文件時(shí)動(dòng)態(tài)調(diào)用公共控件而引起的OLE安全漏洞[9]，該類漏洞不僅可以通過DOC或PPT文檔觸發(fā)，甚至通過RTF文件觸發(fā)。因此，本文在研究RTF文件的OLE對(duì)象嵌入技術(shù)基礎(chǔ)上，提出了一種基于數(shù)據(jù)塊解析及特征數(shù)據(jù)構(gòu)造的OLE對(duì)象漏洞逆向分析方法，并根據(jù)該方法給出了面向RTF文件的OLE對(duì)象漏洞分析流程。實(shí)驗(yàn)測(cè)試證明，本方法能有效檢測(cè)出RTF文件的OLE對(duì)象解析漏洞。此外，與現(xiàn)有的同類檢測(cè)方法相比，本文方法具有更高的檢測(cè)效率。

2　研究背景

2.1OLE對(duì)象鏈接和嵌入技術(shù)

對(duì)象鏈接和嵌入（OLE，object linking and embedding）是一種面向?qū)ο蟮募夹g(shù)，該技術(shù)允許在程序之間鏈接和嵌入對(duì)象數(shù)據(jù)，從而建立復(fù)合文檔[10]。微軟MS Office 97-2003的各種文件格式（DOC、RTF、XLS和PPT等）都采用OLE技術(shù)存儲(chǔ)文件規(guī)范。通過該規(guī)范，一個(gè)文件不僅包含文本，而且可以包括圖形、電子表格、甚至聲音視頻信息。這里以一個(gè)包含OLE結(jié)構(gòu)的RTF文件為例，新建一個(gè)同時(shí)包含“Hello World”文本信息和PNG圖片的RTF文件，提取出其中的OLE結(jié)構(gòu)，通過Offvis分析其OLE結(jié)構(gòu)[11]，如圖1所示。

圖1　Offvis分析RTF的OLE文檔結(jié)構(gòu)

從圖1可以看出，整個(gè)OLE結(jié)構(gòu)類似一個(gè)容器，稱為OLE容器。OLE容器包含了不同的存儲(chǔ)目錄（directory entry），存儲(chǔ)目錄中的OLE數(shù)據(jù)是以流（streams）的形式存儲(chǔ)在倉庫（storages）中，本例中的文本信息存儲(chǔ)在WordDocument流中，圖片信息存儲(chǔ)在Data流中。

2.2RTF的OLE對(duì)象機(jī)制

富文本格式（RTF，rich text format）是微軟進(jìn)行文本和圖像信息格式交換而制定的一種文件格式[12]。RTF文件可以劃分成文件頭和文檔區(qū)兩部分，文件頭和文檔區(qū)都由本文、控制字和控制符組成。其中，控制符由一個(gè)反斜線跟隨單個(gè)非字母字符組成。例如，~代表一個(gè)不換行空格。控制符不需要分隔符?？刂谱质荝TF用來標(biāo)記管理文檔信息的一種特殊格式的命令，其語法格式為：字母序列<分隔符>。例如， tfN 為RTF的版本號(hào)控制字，其中數(shù)字N表示主版本號(hào)。RTF文件解析程序主要是根據(jù)控制字對(duì)文件進(jìn)行解析。表1列出了RTF文件中常用的控制字。

表1　RTF控制字

從表1可以看出，RTF的文件頭中包含 tfN、fonttbl、filetbl和listtable等控制字。文檔區(qū)包含info、pict和object等控制字。其中，object表示OLE對(duì)象控制字。通過object控制字，RTF可以像二進(jìn)制DOC復(fù)合文檔一樣包含圖片、電子表格、聲音和視頻等信息。這些富文本信息在RTF文件中是通過OLE對(duì)象類型控制字來解析，表2列出了RTF中不同的OLE對(duì)象類型控制字。

在表2中，通過objemb控制字可以嵌入圖片、文檔、音頻信息等，通過objocx控制字可以在OLE容器中包含不同的ActiveX控件，通過objlink控制字可以在不同的應(yīng)用程序中鏈接文件。這些對(duì)象類型的數(shù)據(jù)存儲(chǔ)在不同的數(shù)據(jù)區(qū)域，表3列出了可存儲(chǔ)這些數(shù)據(jù)的對(duì)象數(shù)據(jù)控制字。

表2　RTF的OLE對(duì)象類型

表3　RTF的OLE對(duì)象數(shù)據(jù)

表3中的3個(gè)對(duì)象數(shù)據(jù)控制字都可以被對(duì)象類型引用，例如OLE嵌入對(duì)象類型objemb和OLE控件類型objocx的數(shù)據(jù)一般存儲(chǔ)在objdata控制字中。OLE對(duì)象數(shù)據(jù)包括頭部（ObjectHeader）和數(shù)據(jù)流（ObjectStream），它們是通過D0CF11E0A1B11AE1標(biāo)志符進(jìn)行區(qū)分，其中頭部由OLE版本（4字節(jié)）、格式ID（4字節(jié)）、程序名長(zhǎng)度（4字節(jié)）、程序名和數(shù)據(jù)流大?。?字節(jié)）組成。例如，RTF文件中包含OLE控件類型的數(shù)據(jù)信息如下

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

在以上objdata控制字的數(shù)據(jù)信息中，01050000020000001B0000004D53436F6D63746C 4C69622E4C697374566965774374726C2E3200000 0000000000000000E0000為頭部信息，D0CF11E 0A1B11AE1為數(shù)據(jù)流的起始標(biāo)志信息，000000000000000000000000000000003E000300F EFF09000為數(shù)據(jù)流信息。

2.3RTF的OLE對(duì)象安全性問題

根據(jù)2.2節(jié)知道RTF文件包含不同的OLE對(duì)象類型。由于在解析這些對(duì)象類型時(shí)需要調(diào)用公共控件或動(dòng)態(tài)鏈接庫去解析對(duì)象數(shù)據(jù)。此外，RTF 的OLE對(duì)象數(shù)據(jù)存儲(chǔ)在對(duì)象數(shù)據(jù)控制字中，因此objdata等對(duì)象數(shù)據(jù)控制字屬于可存數(shù)據(jù)區(qū)域。在這些可存數(shù)據(jù)區(qū)域中，可以構(gòu)造溢出數(shù)據(jù)，甚至惡意代碼（Shellcode等）。當(dāng)OLE對(duì)象在解析這些特殊構(gòu)造的數(shù)據(jù)時(shí)，將觸發(fā)OLE對(duì)象漏洞，并利用該漏洞執(zhí)行惡意代碼，從而產(chǎn)生RTF文件攻擊。因此，在RTF文件中包含OLE對(duì)象引發(fā)安全漏洞，稱為RTF的OLE對(duì)象漏洞。例如，當(dāng)在RTF文件中嵌入objocx對(duì)象類型的OLE控件TreeView或ListView時(shí)，該控件在解析objdata內(nèi)部數(shù)據(jù)時(shí)會(huì)造成堆棧溢出漏洞，利用該漏洞能進(jìn)行遠(yuǎn)程代碼執(zhí)行攻擊[13]。當(dāng)RTF文件在解析嵌入objocx對(duì)象類型的OLE控件TabStrip時(shí)會(huì)造成內(nèi)存破壞漏洞[14]。在RTF文件中包含objemb對(duì)象類型的TIFF數(shù)據(jù)時(shí)，會(huì)由于OGL.DLL在處理TIFF文件格式數(shù)據(jù)時(shí)產(chǎn)生整數(shù)溢出導(dǎo)致堆溢出漏洞[15]。此外，在RTF漏洞利用攻擊過程中，通常會(huì)利用OLE對(duì)象繞過Windows的安全防護(hù)機(jī)制[16]。例如，在漏洞利用的時(shí)候經(jīng)常需要繞過Windows的地址空間布局隨機(jī)化（ASLR，address space layout randomization）機(jī)制，這時(shí)可以在RTF文件OLE對(duì)象的objdata數(shù)據(jù)區(qū)域中包含未開啟ASLR機(jī)制的控件（MSCOMCTL.OCX，MSGR3EN.DLL等），通過這種方式可以繞過ASLR[17]。

由于 RTF文件經(jīng)常會(huì)伴隨著嵌入的OLE對(duì)象漏洞進(jìn)行攻擊，因此本文重點(diǎn)分析RTF的OLE對(duì)象漏洞。目前，已有一些國外的信息安全專家對(duì)RTF的OLE對(duì)象安全性問題開展相關(guān)研究，如Boldewin設(shè)計(jì)和實(shí)現(xiàn)了一種用于分析和提取RTF中惡意嵌入OLE對(duì)象的工具RTFscan[18]；Bonfa提出了一種基于OLE數(shù)據(jù)結(jié)構(gòu)分析的方法，并設(shè)計(jì)和實(shí)現(xiàn)了用于檢查并解密RTF樣本惡意代碼的OLE漏洞掃描工具pyOLEscanner[19]。這些方法和工具雖然可以判斷RTF文件中是否包含存在漏洞的OLE對(duì)象或Shellcode，但是并不能準(zhǔn)確定位漏洞的觸發(fā)點(diǎn)。本文在此基礎(chǔ)上，通過逆向分析技術(shù)分析RTF文件中的OLE對(duì)象嵌入機(jī)制，并提出一種基于數(shù)據(jù)塊解析及特征數(shù)據(jù)構(gòu)造的OLE對(duì)象漏洞分析方法。

3　面向RTF文件的OLE對(duì)象漏洞分析

3.1RTF的OLE對(duì)象類型逆向分析

通過一個(gè)包含OLE對(duì)象類型的RTF文件（test.rtf）對(duì)OLE對(duì)象嵌入機(jī)制進(jìn)行逆向分析，其關(guān)鍵數(shù)據(jù)信息如下

{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文件數(shù)據(jù)中，object控制字表示解析的是一個(gè)OLE對(duì)象類型；objocx控制字表示該對(duì)象類型為OLE控件類型；objclass控制字引用MSComctlLib.ListViewCtrl.2參數(shù)，該參數(shù)表示 OLE對(duì)象類型調(diào)用 MSComctlLib中的ListViewCtrl.2控件；objdata控制字表示對(duì)象數(shù)據(jù)，這些對(duì)象數(shù)據(jù)采用十六進(jìn)制形式存儲(chǔ)。將objdata控制字對(duì)象數(shù)據(jù)的頭部信息通過Winhex進(jìn)行解析[20]，如圖2所示。

從圖2可以看出，根據(jù)OLE對(duì)象數(shù)據(jù)的頭部組成，OLE版本的值為0x00000501；格式ID的值為0x00000002，表示OLE對(duì)象嵌入在RTF文件中；程序名長(zhǎng)度的值為0x0000001B，表示程序名的長(zhǎng)度為27字節(jié)；程序名為MSComctlLib.ListViewCtrl.2，數(shù)據(jù)流大小的值為0x00000E00，表示數(shù)據(jù)流信息的大小是3 584字節(jié)。

下面通過 Windbg對(duì) MSComctlLib.List-ViewCtrl.2指定的ListViewCtrl.2控件進(jìn)行逆向調(diào)試[21]，發(fā)現(xiàn)RTF在解析該ObjectStream數(shù)據(jù)時(shí)，是將數(shù)據(jù)讀取到?？臻g中，如圖3(a)所示。例如，讀取OLE對(duì)象中ObjectStream的01EFCDAB 0000050000000000060000000800008005000080B 0303A03數(shù)據(jù)的關(guān)鍵代碼，如圖3(b)所示。

從圖3(b)可以看到在解析ObjectStream數(shù)據(jù)時(shí)，通過rep movs dword ptr es:[edi],dword ptr[esi]指令，將文檔中數(shù)據(jù)讀取至棧（如圖3(a)所示）中。這種串復(fù)制指令很容易造成堆棧溢出或內(nèi)存破壞，因此RTF在解析包含OLE對(duì)象的文檔時(shí)可能存在OLE對(duì)象漏洞。

3.2基于數(shù)據(jù)塊解析和特征數(shù)據(jù)構(gòu)造的OLE對(duì)象漏洞分析

根據(jù)3.1節(jié)對(duì)RTF文件中的OLE對(duì)象類型分析，知道當(dāng)RTF中包含OLE對(duì)象，并在解析ObjectStream時(shí)可能會(huì)產(chǎn)生OLE對(duì)象漏洞，本小節(jié)在此基礎(chǔ)上進(jìn)行基于數(shù)據(jù)塊解析的OLE對(duì)象漏洞分析。分析調(diào)試工具為Windbg[21]，RTF分析文檔為3.1小節(jié)中的test.rtf，RTF文件解析程序?yàn)镸S Word 2010。

RTF文件中的 OLE對(duì)象數(shù)據(jù)保存在ObjectStream中，而ObjectStream內(nèi)部數(shù)據(jù)按照屬性進(jìn)行分類，具有相同屬性的數(shù)據(jù)屬于同一個(gè)數(shù)據(jù)塊，例如OCXNAME數(shù)據(jù)塊、Table數(shù)據(jù)塊，Contents數(shù)據(jù)塊等，因此ObjectStream中一般存在多個(gè)數(shù)據(jù)塊。RTF文件解析程序通過類標(biāo)識(shí)符（CLSID，class identifier）指定解析ObjectStream數(shù)據(jù)塊時(shí)調(diào)用的控件類型。分析發(fā)現(xiàn)在函數(shù)OLE32.ReadClassStg中讀取 OLE對(duì)象中的CLSID

BDD1F04B-858B-11D1-B16A-00-C0F0283628，該控件位于MSCOMCTL.OCX中。通過Windbg在解析該數(shù)據(jù)塊入口的位置處下斷點(diǎn)，確定解析該數(shù)據(jù)塊的部分關(guān)鍵代碼如圖4所示。

圖2　OLE對(duì)象數(shù)據(jù)的頭部信息

圖3　RTF解析ObjectStream關(guān)鍵代碼

在圖4中，地址0x276008F1處調(diào)用的函數(shù)為OLE32.CExposedDocFile::openstream。該函數(shù)的作用是打開一個(gè)Stream流，通過其中一個(gè)參數(shù)[275E56A0]=Contents知道該處打開的是一個(gè)內(nèi)容為Contents的Stream流，因此這里實(shí)際上要解析的是OLE對(duì)象中的Contents數(shù)據(jù)塊。解析Contents數(shù)據(jù)塊前8個(gè)字節(jié)的關(guān)鍵代碼如圖5所示。

圖4　解析OLE對(duì)象數(shù)據(jù)部分關(guān)鍵代碼

在圖5中，地址0x2758AF04處調(diào)用的函數(shù)為OLE32.CExposedStream::Read，該函數(shù)的作用是讀入Stream流，其中第2個(gè)參數(shù)為要讀入數(shù)據(jù)返回的buffer，第3個(gè)參數(shù)為要讀入數(shù)據(jù)的大小。在這里buffer的地址為0x001278E4，是一個(gè)?？臻g的地址，讀取的數(shù)據(jù)大小為0x08字節(jié)，因此通過OLE32.CExposedStream::Read將Contents數(shù)據(jù)塊的前8個(gè)字節(jié)讀入棧空間。讀完后，在地址0x2758AF08和0x2758AF18處分別對(duì)讀入的數(shù)據(jù)進(jìn)行校驗(yàn)，校驗(yàn)是否為固定數(shù)據(jù)0x12344321和0x08。如果校驗(yàn)成功，則繼續(xù)讀取Contents數(shù)據(jù)塊余下的數(shù)據(jù)。如果校驗(yàn)失敗，則退出該數(shù)據(jù)塊校驗(yàn)進(jìn)程。Contents數(shù)據(jù)塊其他數(shù)據(jù)的讀取方式也是將數(shù)據(jù)讀取至棧區(qū)，再對(duì)數(shù)據(jù)進(jìn)行校驗(yàn)，其讀取校驗(yàn)過程如圖6所示。

從圖6可以看出，在讀取數(shù)據(jù)塊中的數(shù)據(jù)時(shí)不是一次性讀完，而是讀取其中一部分?jǐn)?shù)據(jù)，邊讀邊校驗(yàn)。只有當(dāng)校驗(yàn)通過時(shí)才會(huì)繼續(xù)讀取數(shù)據(jù)直至數(shù)據(jù)讀取完畢，否則剩余數(shù)據(jù)也不會(huì)再讀取。根據(jù)圖6的流程，最終讀取的數(shù)據(jù)如下

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

圖5　解析Contents數(shù)據(jù)塊部分關(guān)鍵代碼

在以上數(shù)據(jù)中，當(dāng)讀取校驗(yàn)Contents數(shù)據(jù)塊尾部中的0C000000436F626A6400000008000000 E53746C4C69622E4數(shù)據(jù)時(shí)，讀入該部分?jǐn)?shù)據(jù)的關(guān)鍵解析代碼如圖7所示。

從圖7可以看出，在地址0x275C89CA處，通過sub esp,14h指令開辟0x14大小的空間用于存儲(chǔ) Contents數(shù)據(jù)塊尾部數(shù)據(jù)，并在地址0x275C89DA處第1次調(diào)用函數(shù)MSCOMCTL.GetClassObject，該函數(shù)讀入數(shù)據(jù)關(guān)鍵代碼如圖8所示。

圖6　Contents數(shù)據(jù)塊的讀取校驗(yàn)流程

從圖8可以看出，在地址0x275C8783處，通 過 call dword ptr[eax+0Ch]調(diào) 用 OLE32.CExposedStream::Read函數(shù)，從Contents數(shù)據(jù)塊尾部讀取1~4字節(jié)的數(shù)據(jù)至棧區(qū)。隨后在地址0x275C878D處，cmp dword ptr[ebp-4],edi指令校驗(yàn)讀入的數(shù)據(jù)是否和0x0C相等（參見圖7地址0x275c89d3處的push 0Ch）。如果不相等，則不讀取數(shù)據(jù)；如果相等，則從數(shù)據(jù)塊中讀取0x0C字節(jié)數(shù)據(jù)至棧區(qū)，并且對(duì)讀取數(shù)據(jù)中的前4個(gè)字節(jié)是否為0x6A626F43進(jìn)行校驗(yàn)。如果校驗(yàn)不成功，則退出當(dāng)前數(shù)據(jù)塊的解析；如果檢驗(yàn)成功，則判斷所讀取的0x0C字節(jié)數(shù)據(jù)中的后4個(gè)字節(jié)是否大于或等于0x08（參見圖7地址0x275c89f3處的cmp dword ptr[ebp-0Ch],8指令）。如果小于0x08，則不讀取數(shù)據(jù)，并退出當(dāng)前數(shù)據(jù)塊的解析；如果大于或等于 0x08，則繼續(xù)調(diào)用函數(shù)MSCOMCTL.GetClassObject從數(shù)據(jù)塊中取4個(gè)字節(jié)的數(shù)據(jù)至棧區(qū)。根據(jù)圖8地址0x275C878D處的cmp dword ptr[ebp-4],edi指令，校驗(yàn)讀入棧區(qū)的數(shù)據(jù)是否和[ebp-0Ch]相等（參見圖7地址0x275c89fd處的push dword ptr[ebp-0Ch]指令）。如果不相等，則不讀取數(shù)據(jù)，并退出當(dāng)前數(shù)據(jù)塊的解析；如果相等，則從數(shù)據(jù)塊中讀取[ebp-0Ch]字節(jié)數(shù)據(jù)至棧區(qū)。

圖7　解析Contents數(shù)據(jù)塊尾部數(shù)據(jù)關(guān)鍵代碼

圖8　MSCOMCTL.GetClassObject部分關(guān)鍵代碼

根據(jù)以上分析發(fā)現(xiàn)，程序剛開始只開辟了0x14大小的?？臻g，第1次讀取了0x0C字節(jié)數(shù)據(jù)至該區(qū)域。如果該區(qū)域中的最后4個(gè)字節(jié)大于或等于0x08，那么程序會(huì)繼續(xù)讀取數(shù)據(jù)至棧區(qū)。如果在接下來調(diào)用MSCOMCTL.GetClassObject時(shí)，數(shù)據(jù)校驗(yàn)成功，就會(huì)讀入超過0x08個(gè)字節(jié)數(shù)據(jù)至棧區(qū)，從而造成棧溢出。

3.3RTF的OLE對(duì)象漏洞分析流程

根據(jù)3.2節(jié)對(duì)OLE對(duì)象漏洞的分析，得到RTF中的OLE對(duì)象漏洞分析流程，如圖9所示。

圖9　RTF的OLE對(duì)象漏洞分析流程

從圖9可以看出，在解析RTF文件時(shí)，首先確定包含的OLE對(duì)象類型，并將對(duì)象數(shù)據(jù)讀至緩沖區(qū)中；接著校驗(yàn)對(duì)象數(shù)據(jù)，并對(duì)讀取校驗(yàn)成功數(shù)據(jù)的代碼進(jìn)行分析；最后根據(jù)代碼執(zhí)行流程，在數(shù)據(jù)塊中相應(yīng)位置構(gòu)造特征數(shù)據(jù)，并判斷是否會(huì)造成溢出。如果不溢出，則讀取接下來的數(shù)據(jù)；如果溢出，則定位漏洞。

4　測(cè)試結(jié)果與分析

本節(jié)將對(duì)3.3節(jié)提出的OLE對(duì)象漏洞分析流程進(jìn)行實(shí)驗(yàn)測(cè)試，實(shí)驗(yàn)環(huán)境為Intel(R)Core(TM)i5-3230M CPU、4 GB內(nèi)存、OS為Microsoft Windows 7 SP1。首先，通過一個(gè)實(shí)例測(cè)試本方法的正確性；然后，針對(duì)不同OLE對(duì)象的漏洞進(jìn)行測(cè)試，并與現(xiàn)有工具進(jìn)行比較，證明本方法具有更高的檢測(cè)效率；最后，通過構(gòu)造畸形測(cè)試用例來測(cè)試本方法的抗干擾性。

4.1實(shí)例測(cè)試

根據(jù)3.3節(jié)的分析流程，OLE對(duì)象數(shù)據(jù)是能否觸發(fā)漏洞的關(guān)鍵，只有在OLE對(duì)象類型中構(gòu)造合適的對(duì)象數(shù)據(jù)才能造成緩沖區(qū)溢出，觸發(fā)漏洞。在RTF的objocx對(duì)象類型中，首先通過3.2節(jié)對(duì)objdata對(duì)象數(shù)據(jù)的Contents數(shù)據(jù)塊尾部分析，發(fā)現(xiàn)由Contents數(shù)據(jù)塊尾部的第1至第4字節(jié)所構(gòu)成的8位16進(jìn)制數(shù)等于0x0C，且第5至第8字節(jié)的 8位 16進(jìn)制等于 0x6A626F43時(shí)，即(4321)H=0x0C，(8765)H=0x6A626F43，才能將指定大小的數(shù)據(jù)復(fù)制到緩沖區(qū)中。該復(fù)制數(shù)據(jù)的大小由Contents數(shù)據(jù)塊尾部的第1至第4字節(jié)構(gòu)成的二進(jìn)制數(shù)決定，即(4321)H。根據(jù)圖9中的數(shù)據(jù)讀入和數(shù)據(jù)校驗(yàn)判斷條件構(gòu)造Contents數(shù)據(jù)塊尾部第1至第8字節(jié)的特征數(shù)據(jù)為0C000000436F626A，這樣可以使得第1次校驗(yàn)成功，而且會(huì)第2次調(diào)用MSCOMCTL.GetClassObject（參見圖8）。

接著，根據(jù)圖9中的數(shù)據(jù)溢出判斷條件，通過特征數(shù)據(jù)構(gòu)造方法，將objdata對(duì)象數(shù)據(jù)的Contents數(shù)據(jù)塊尾部第9至第20字節(jié)的數(shù)據(jù)構(gòu)造成 640000008800000088000000。最后，根據(jù)Contents數(shù)據(jù)塊尾部第9至第20字節(jié)構(gòu)造的數(shù)據(jù)在Contents數(shù)據(jù)塊尾部的剩余數(shù)據(jù)中構(gòu)造0x88大小的特征數(shù)據(jù)aaaa…。這樣，在第2次的MSCOMCTL.GetClassObject函數(shù)調(diào)用中，地址0x275C879E處調(diào)用Kernel32.HeapAlloc函數(shù)（參見圖8）開辟一段大小0x88字節(jié)堆空間，在地址0x275C87B5處調(diào)用函數(shù)OLE32.CExposedStream:: Read（參見圖8）繼續(xù)從數(shù)據(jù)塊中讀取大小為0x88字節(jié)數(shù)據(jù)至分配的堆空間中。最后，在地址0x275C87CB處調(diào)用指令 rep movs dword ptr es:[edi],dword ptr ds:[esi]（參見圖8）將這些數(shù)據(jù)讀取至棧區(qū)，如圖10所示。

圖10　棧溢出

從圖10可以看出，在數(shù)據(jù)塊中構(gòu)造的數(shù)據(jù)aaaa…成功讀入棧區(qū)，并且造成溢出。通過這個(gè)實(shí)例證明了本文分析方法的正確性。

4.2與其他工具比較測(cè)試

下面通過Windbg的腳本調(diào)試功能，創(chuàng)建一個(gè)模擬Word 2010解析RTF中OLE對(duì)象漏洞流程的腳本文件。然后，通過Windbg對(duì)不同的漏洞樣本進(jìn)行測(cè)試，并與現(xiàn)有的RTFScan[18]和pyOLEscanner[19]工具進(jìn)行比較。這里選擇10個(gè)Word漏洞進(jìn)行測(cè)試，包括最常攻擊利用的漏洞（CVE-2010-3333、CVE-2012-0158、CVE-2012-1856、 CVE-2013-3906、 CVE-2014-1761和CVE-2014-6357）以及2015年新發(fā)現(xiàn)的OLE對(duì)象漏洞（CVE-2015-1770、CVE-2015-2424、CVE-2015-1641和CVE-2015-2369）。為了更好地對(duì)比3種不同的檢測(cè)方法，對(duì)每個(gè)CVE編號(hào)的漏洞通過構(gòu)造不同特征數(shù)據(jù)、變換Shellcode及其加密方式，并添加額外正常OLE控件等規(guī)則生成20個(gè)測(cè)試樣本（總共200個(gè)測(cè)試樣本），表4記錄了采用不同的方法檢測(cè)到的樣本數(shù)量。

表4　本文方法與其他工具的測(cè)試結(jié)果對(duì)比

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可以看出，對(duì)于CVE-2012-0158、CVE-2012-1856、CVE-2013-3906、CVE-2014-6357、CVE-2015-1770、CVE-2015-2424、CVE-2015-2369 和CVE-2015-1641，本文方法的檢測(cè)效果明顯優(yōu)于其他兩種方法，由于這8個(gè)漏洞都是典型的OLE對(duì)象漏洞，根據(jù)3.3節(jié)，通過找到控件標(biāo)識(shí)符CLSID，隨后加載控件調(diào)用指定的控件解析對(duì)應(yīng)數(shù)據(jù)塊，而這8個(gè)漏洞的CLSID和控件都可以定位到，接著在讀取數(shù)據(jù)至緩沖區(qū)時(shí)進(jìn)行代碼分析，并通過樣本中的特征數(shù)據(jù)測(cè)試定位到漏洞。對(duì)于CVE-2010-3333和CVE-2014-1761，本文方法沒有檢測(cè)出異常樣本，經(jīng)分析發(fā)現(xiàn)這兩個(gè)漏洞分別是RTF繪圖屬性緩沖區(qū)溢出漏洞和RTF數(shù)組溢出漏洞，所以本文方法檢測(cè)不到該樣本。此外，對(duì)本文方法未檢測(cè)出的其他漏洞樣本分析發(fā)現(xiàn)，主要是由于對(duì)象類型疊加或構(gòu)造的特征數(shù)據(jù)未造成溢出，從而檢測(cè)不到異常。pyOLEscanner的檢測(cè)效率優(yōu)于RTFScan，這是由于pyOLEscanner可以檢測(cè)文檔中是否還有宏和ActiveX等控件。例如，通過對(duì)OLE對(duì)象數(shù)據(jù)結(jié)構(gòu)進(jìn)行分析，發(fā)現(xiàn)在解析CVE-2015-1770漏洞樣本數(shù)據(jù)時(shí)，加載了ActiveX控件OSF.DLL，而pyOLEscanner存在OSF.DLL的解析模塊，因此可以檢測(cè)到該漏洞。RTFScan相比其他兩種方法，其檢測(cè)效率最差，能夠檢測(cè)到的各個(gè)漏洞測(cè)試樣本數(shù)量有限，主要原因是RTFScan靠檢測(cè)文檔中的Shellcode，隨著Shellcode以及加密技術(shù)的發(fā)展，文檔中的Shellcode越來越難以通過特征匹配的方式定位，因此對(duì)于比較復(fù)雜的漏洞樣本文件，RTFscan幾乎很難檢測(cè)到。

4.3抗干擾性測(cè)試

RTF解析程序不但可以正確地解釋基于文獻(xiàn)[12]語法規(guī)范生成的RTF文件，而且能夠忽略它不知道或者未使用的控制字，并且能正確地略過被*控制符標(biāo)記的部分。因此，RTF文件中往往存在沒有完全符合語法規(guī)范的數(shù)據(jù)格式。在實(shí)際的漏洞樣本中，為了躲避檢測(cè)，經(jīng)常會(huì)在樣本中插入一些無意義的數(shù)據(jù)干擾漏洞檢測(cè)。由于本文提出的方法需要對(duì)object、objocx、OLE起始標(biāo)志位以及CLSID進(jìn)行分析， 因此本測(cè)試采用網(wǎng)絡(luò)上公開的300例測(cè)試用例對(duì)本文方法的抗干擾性進(jìn)行測(cè)試[22]。在這300例測(cè)試用例中，分別對(duì)object和objocx采用空格等字符進(jìn)行混淆，對(duì)OLE起始標(biāo)志位和CLSID采用轉(zhuǎn)義字符進(jìn)行混淆，表5分別列出了不同字段未檢測(cè)到的測(cè)試用例數(shù)目。

表5　抗干擾測(cè)試結(jié)果

在表5中可以看出，在300例的測(cè)試樣本中，總共有84例漏洞樣本未檢測(cè)出，其中object控制字35例，objdata控制字24例，OLE起始標(biāo)志位10例，CLSID 15例。通過對(duì)測(cè)試樣本的數(shù)據(jù)分析發(fā)現(xiàn)，object和objocx的混淆影響檢測(cè)結(jié)果最嚴(yán)重。當(dāng)樣本中添加空格混淆，例如在樣本中控制字可以表現(xiàn)為object等類似變形的字符串時(shí)，由于本文解析包含OLE對(duì)象的RTF文件時(shí)，是通過查找標(biāo)記為object與objocx的字符串來確定包含的OLE對(duì)象類型，因此對(duì)檢測(cè)效果影響較大。CLSID和OLE起始標(biāo)志位由數(shù)據(jù)串組成，可 以采用 d

临夏县| 临邑县| 新乐市| 宝兴县| 确山县| 东城区| 三门县| 保亭| 天峨县| 洪湖市| 舟山市| 双桥区| 高州市| 沿河| 三原县| 武清区| 青岛市| 中山市| 泽普县| 焉耆| 会理县| 商城县| 安塞县| 航空| 资兴市| 太谷县| 遵化市| 丰城市| 南皮县| 西吉县| 沙坪坝区| 馆陶县| 通渭县| 静乐县| 会同县| 阿拉善盟| 阳东县| 玉山县| 大洼县| 比如县| 仁寿县|