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

2016-09-22 10:51:45樂德廣章亮龔聲蓉鄭力新吳少剛

網絡與信息安全學報 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文件可以劃分成文件頭和文檔區兩部分，文件頭和文檔區都由本文、控制字和控制符組成。其中，控制符由一個反斜線跟隨單個非字母字符組成。例如，~代表一個不換行空格?？刂品恍枰指舴??？刂谱质荝TF用來標記管理文檔信息的一種特殊格式的命令，其語法格式為：字母序列<分隔符>。例如， 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字節）、程序名和數據流大?。?字節）組成。例如，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個字節讀入?？臻g。讀完后，在地址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大小的?？臻g，第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起始標志位由數據串組成，可以采用 d

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

1 引言

2 研究背景

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

4 測試結果與分析

1　引言

2　研究背景

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

4　測試結果與分析