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

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

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

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

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

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


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


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


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

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

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

了解EMF格式

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


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

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

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

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

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

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

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


模糊測試的考慮事項

1.選擇fuzzer

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


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

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


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


3.樣本的生成

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


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


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

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


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

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


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


5.最終結(jié)果

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


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

使用崩潰樣本啟動WinDbg實例，結(jié)果：


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

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