Gdiplus.dll：未打補(bǔ)丁（左）vs已打補(bǔ)?。ㄓ遥?/div>
通過考察相關(guān)代碼在打補(bǔ)丁前后的變化情況，我們可以推斷出許多有用的信息。例如，觀察打過補(bǔ)丁的方法的數(shù)量，可以推測(cè)該特定更新的重要性。通過觀察和比較單個(gè)模塊的連續(xù)補(bǔ)丁，可以幫我們了解其開發(fā)過程，例如特定組件中出現(xiàn)的問題/漏洞的類別等。同時(shí)，這種方法還可以幫助安全研究人員識(shí)別模糊測(cè)試的目標(biāo)，以及哪些功能更可能存在漏洞。

利用IDA插件BinDiff，我們可以對(duì)比二進(jìn)制代碼在打補(bǔ)丁前后的變化情況，具體如下所示：
通過比較發(fā)現(xiàn)，DoRotatedStretchBlt方法確實(shí)發(fā)生了一些變化，并且這里還具有較高的置信度。下面，讓我們?cè)敿?xì)看看圈起來部分的變化情況。
BinDiff插件的顏色的含義：

綠色節(jié)點(diǎn)表示在兩個(gè)可執(zhí)行文件中具有相同指令的基本塊；

紅色節(jié)點(diǎn)表示比較算法無法找到等價(jià)物的基本塊；

黃色節(jié)點(diǎn)表示算法可以找到等價(jià)物的節(jié)點(diǎn)，但是在不同版本中，某些指令已經(jīng)發(fā)生了變化。

在我們的例子中，我們可以看到打過補(bǔ)丁的DLL中有一些紅色基本塊，所以，我們可以使用IDA Hex-Rays反匯編程序來進(jìn)一步查看實(shí)際的差異。


通過觀察這個(gè)補(bǔ)丁，可以看出它處理的是一種典型的安全問題——使用memcpy時(shí)沒有進(jìn)行適當(dāng)邊界檢查。該補(bǔ)丁似乎是用于處置Size參數(shù)的不同值的，以避免發(fā)生溢出。奇怪的是，并非所有的情況都得到了相應(yīng)的處理。這是因?yàn)?，與Windows補(bǔ)丁程序的情況一樣，補(bǔ)丁程序不會(huì)出現(xiàn)在漏洞所在的確切位置。進(jìn)一步的研究表明，該補(bǔ)丁程序的另一部分位于StretchBLT記錄的處理程序中：


我們注意到，除了GdiPlus!pfnIsValidEnhMetaRecordOffExt方法（該方法也存在于未打補(bǔ)丁的程序庫中）之外，該補(bǔ)丁程序中還含有另一個(gè)驗(yàn)證方法，即GdiPlus!bValidateAndExpandBuffers方法。后者的作用是清理Src緩沖區(qū)（pjBits）和Ubytes（v21）參數(shù)。然后，如果滿足某些條件的話，DoStretchBlt將調(diào)用存在漏洞的函數(shù)。


如果針對(duì)hdc_flag的AND運(yùn)算的結(jié)果為true，則調(diào)用相關(guān)的函數(shù)。變量hdc存放的是一個(gè)Windows設(shè)備上下文的引用。而所謂的設(shè)備上下文其實(shí)就是一種結(jié)構(gòu)體，用于定義一組圖形對(duì)象及其相關(guān)屬性，以及影響輸出的圖形模式。在我們的例子中，圖形對(duì)象包含一個(gè)用于剪切、噴涂和繪制操作的區(qū)域。

總之，要利用這個(gè)漏洞，需要控制DoRotatedStretchBlt方法的Src和Ubytes參數(shù)。所以，我們首先必須設(shè)法滿足這一要求。了解如何訪問該函數(shù)的最佳方式，就是使用IDA的調(diào)用圖功能。

如您所見，我們可以通過調(diào)用不同的處理程序（例如，bHandlePlgBlt或bHandleSetDIBitsToDev）來執(zhí)行DoRotatedStretchBlt操作。這些似乎是不同EMF記錄的處理程序。我們的問題是如何處理不同的EMF記錄？

了解EMF格式

增強(qiáng)型圖元文件格式（Enhanced metafile format，EMF）是一種用于存儲(chǔ)圖形圖像的可移植文件格式。EMF元文件中存放的是順序記錄，這些記錄經(jīng)過解析和處理后，可以在任何輸出設(shè)備上顯示文件中存儲(chǔ)的圖像。這個(gè)程序庫必須能夠以某種方式解釋這些記錄的類型，這樣，當(dāng)處理EMF文件時(shí)，就能為其提供正確的處理程序。在二進(jìn)制文件中進(jìn)行快速搜索，就能找到_pdofnDrawingOrders方法：


我們可以發(fā)現(xiàn)，這里列舉了所有受支持的記錄，包括我們的bHandleStretchBlt記錄處理程序。下面，我們將設(shè)法觸發(fā)DrawingOrder操作。

GdiPlus!bParseWin32Metafile方法將解析WMF文件頭部，如果其中存在有效的EMF記錄，它將通過從_pdofnDrawingOrders調(diào)用正確的處理程序來解析它們。隨后，該解析方法會(huì)被GdipConvertEmfToWmFBits調(diào)用。除此之外，我們沒有發(fā)現(xiàn)針對(duì)該方法的其他交叉引用，這表明必定存在一些外部API。通過閱讀Win GDI+文檔，發(fā)現(xiàn)它似乎不推薦使用GdipConvertEmfToWmFBits，所以我們?cè)贛etafile類中為其提供了一個(gè)封裝器，即Metafile::EmfToWmfBits.。目前來看，我們似乎勝利在望了，至少已經(jīng)看到了曙光。

讓我們先暫停前進(jìn)的步伐，回顧一下前面講過的內(nèi)容：

· 易受攻擊的方法gdiplus!DoRotatedStretchBlt是由gdiplus!DoStretchBlt調(diào)用的，而后者是用于處理EMF_STRETCHBLT記錄類型的。

· 如果為設(shè)備句柄設(shè)置了某個(gè)標(biāo)志（值4），則會(huì)調(diào)用易受攻擊的方法。

· 我們最終可以通過觸發(fā)Metafile::EmfToWmfBits操作來調(diào)用易受攻擊的方法，其中一個(gè)參數(shù)是包含EMF_STRETCHBLT記錄的EMF文件。

現(xiàn)在，我們已經(jīng)通過逆向分析獲得了足夠的信息，所以逆向工作可以告一段落了；接下來，我們要做的事情是，通過模糊測(cè)試找到一個(gè)能夠?qū)е乱资芄舻姆椒òl(fā)生崩潰的EMF文件，同時(shí)也希望能找到其他讓人感興趣的東西。


模糊測(cè)試的考慮事項(xiàng)

1.選擇fuzzer

對(duì)于Windows二進(jìn)制文件來說，當(dāng)前最先進(jìn)的模糊測(cè)試框架是WinAFL和Peach Fuzzing Framework。在本文中，我們將使用WinAFL，因?yàn)樗且环N基于突變的、覆蓋率反饋驅(qū)動(dòng)型的模糊引擎。用于Linux應(yīng)用程序的AFL的詳細(xì)介紹，請(qǐng)參閱這篇文章。對(duì)于插樁技術(shù)，我們采用的是DynamoRio，這是一種運(yùn)行時(shí)檢測(cè)框架，能夠在塊覆蓋率模式下運(yùn)行。


2.創(chuàng)建測(cè)試工具

現(xiàn)在，必須創(chuàng)建一個(gè)使用易受攻擊的GdiPlus.dll庫的Windows GUI應(yīng)用程序。最終的測(cè)試工具看起來像這樣：


首先，我們會(huì)讀取作為參數(shù)提供的EMF文件。然后，我們將啟動(dòng)一個(gè)EmfToWmfBits操作（將第136行），這將有望觸發(fā)該漏洞。接著，觸發(fā)針對(duì)EMF文件的Metafile::EmfToWmfBits操作后，通過釋放使用過的組件并關(guān)閉打開的文件來清理環(huán)境。


3.樣本的生成

為了得到一個(gè)包含EMR_STRETCHBLT記錄的EMF文件，我們專門研究了WinGDI和GDI+文檔，并找到了一個(gè)簡(jiǎn)單的生成器，具體如下所示：


我們還在初始語料庫中的EMF文件中通過了其他記錄類型以提高覆蓋率，以增加導(dǎo)致其崩潰的機(jī)會(huì)。


4.語料庫最小化與覆蓋率

對(duì)模糊測(cè)試進(jìn)行優(yōu)化時(shí)，其中一個(gè)重要步驟就是語料庫的最小化。該過程將刪除無法顯著改善代碼覆蓋率的樣本，以防止在這些樣本上浪費(fèi)CPU周期。利用winafl-cmin.py腳本（它是WinAFL存儲(chǔ)庫的一部分）處理最初的32個(gè)樣本的EMF語料庫后，最終找到了10個(gè)重要的樣本：


這里要做的是，在DynamoRio的運(yùn)行時(shí)檢測(cè)模式下，通過測(cè)試工具運(yùn)行所有初始測(cè)試用例，同時(shí)，在每次運(yùn)行時(shí)捕獲感興趣的庫中已到達(dá)的基本塊。

使用IDA的Lighthouse插件，可以查看最終語料庫是否具有良好的覆蓋率：


如您所見，我們的目標(biāo)GdiPlus!GdipEmfToWmfBits具有很好的覆蓋率，同時(shí)，程序庫的大部分代碼也具有很好的覆蓋率。


5.最終結(jié)果

經(jīng)過1天21小時(shí)的測(cè)試后，我們找到了80多個(gè)庫崩潰：


使用BugID對(duì)它們進(jìn)行分類，發(fā)現(xiàn)有多個(gè)樣本能導(dǎo)致我們感興趣的方法發(fā)生崩潰：
BugID的測(cè)試報(bào)告：GdiPlus!DoRotatedStretchBlt中可能存在RCE漏洞

使用崩潰樣本啟動(dòng)WinDbg實(shí)例，結(jié)果：


WinDbg的輸出：通過模糊測(cè)試獲得的示例，觸發(fā)與CVE-2019-0618相對(duì)應(yīng)的崩潰；綠框內(nèi)是stacktrace數(shù)據(jù)，紅框內(nèi)是崩潰分析數(shù)據(jù)

通過類似的方式，我們獲得了與CVE-2019-0614、CVE-2019-0618和CVE-2019-0619相關(guān)的庫崩潰。此外，我們?cè)谀：郎y(cè)試過程中發(fā)現(xiàn)了一些其他方面的庫漏洞，并將這些漏洞也提交給了微軟。