怎么對Microsoft Outlook漏洞的深入分析

這篇文章將為大家詳細講解有關怎么對Microsoft Outlook漏洞的深入分析，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

寫在前面的話

MicrosoftOutlook是微軟Office套件中的一個組件，它可以用來發送和接收電子郵件，管理聯系人，記錄和跟蹤日程計劃，或執行其他任務。近期，研究人員在Outlook 2010至Outlook 2019版本以及Office 365 ProPlus中發現了一個堆崩潰漏洞，Windows平臺下的32/64版本均會受到該漏洞影響。攻擊者可使用惡意RWZ文件來觸發該漏洞，當Outlook收到惡意RWZ文件內容時，它只會分配少量堆內存，并且缺少恰當的邊界檢測，最終導致堆內存越界寫入。

復現漏洞

為了復現該漏洞，我們需要運行Microsoft Outlook，然后點擊“規則=>管理規則&警報=>選項=>導入規則”，選擇可以觸發Outlook崩潰的PoC文件。

下面給出的就是發生崩潰時的棧調用情況：

分析漏洞

我們可以從棧調用數據中看到，當堆內存被釋放時就發生程序崩潰了。因為我們無法判單堆釋放時發生了什么情況，所以我們需要打開完整的堆內存頁表來跟蹤堆內存的數據變化，命令如下：

YOUR_WINDBG_INSATALL_LOCATION\gflags.exe/p /enable outlook.exe /full

上述命令返回的結果如下，表明命令已成功執行了。

接下來，我們再次打開Outlook，選擇PoC文件并監控崩潰發生時新的棧空間情況：

現在我們可以看到，ECX指向的非0內存地址時不可讀的，并且在向這個內存地址寫入數據時會發生異常，很有可能是因為程序在嘗試向未分配（或未釋放）的內存地址寫入數據。我們可以通過檢測內存頁分配情況來驗證這種猜想，此時我們會看到內存仍然擁有Reserve屬性：

現在我們需要弄清楚，為什么程序會向未使用的內存頁寫入數據。通過靜態分析，我們可以看到ECX的值來自于EDI，而EDI貌似會在程序調用MAPIAllocateBuffer后被修改：

靜態分析的結果表明，MAPIAllocateBuffer函數其實是RtlAllocateHeap的封裝函數，而這個函數會確保請求的內存大小參數不會超過0x7FFFFFF7。但是，它無法檢測該參數的值是否為0，因為實際分配的堆大小為8字節，超過了請求的堆大小，這8個字節填充值為0x0000000001000010。接下來，MAPIAllocateBuffer會返回這8個字節后面的堆地址。因此，在調用MAPIAllocateBuffer之后EDI的值為8 + 分配的堆地址（來自RtlAllocateHeap）：

根據上面的靜態分析結果，我們可以大致判斷導致漏洞出現的原因為整型溢出問題。通過調式后我們發現，調用MAPIAllocateBuffer時的堆大小參數為0，因為MAPIAllocateBuffer請求分配的堆大小為0+8=8，此時RtlAllocateHeap不會返回錯誤，而是返回正確的堆地址。MAPIAllocateBuffer會使用這8字節來寫入地址0x0000000001000010，然后把無效的內存地址返回給用戶：

接下來，我們需要弄清楚請求的堆大小值為什么會變成0。原來，0值來自于當前的一個函數參數：arg_4(eax = arg_4 * 4 + 4)。但是，當這個函數被調用時，arg_4的值并非傳遞進來的參數值，這也就意味著arg_4的值被修改了。分析后我們發現，罪魁禍首是其子函數sub_65F7DA：

在對子函數sub_65F7DA進行分析后，我們發現它也是一個封裝函數。原來，這個函數是ReadFile，而arg_4得值實際上來自于PoC文件：

調試結果表明，arg_4讀取到的文件內容為0xFFFFFFFF，因此堆內存的分配大小就是0xFFFFFFFF * 4 + 4 = 0（整型溢出）。然而，程序并不會檢測這種錯誤，最終導致了越界寫入的情況出現：

在PoC文件中我們可以看到，并不存在0xFFFFFFFF這個值：

將其修改為0xAABBCCDD后再次進行調試，我們就可以證實溢出就是由這4個字節造成的：

在安裝了修復補丁之后，我們對前后的程序代碼進行了對比，我們發現補丁增加了對請求分配堆內存大小的驗證：

因此，廣大用戶請盡快安裝更新補丁以防止攻擊者利用該漏洞實施攻擊。

漏洞信息

MS.Outlook.CVE-2018-8587.Remote.Code.Execution

關于怎么對Microsoft Outlook漏洞的深入分析就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。