深入分析Microsoft Outlook漏洞CVE-2018-8587

新聞 12-20

Microsoft Outlook是Microsoft Office套裝的組件之一，廣泛用於發送和接收電子郵件、管理聯繫人、記錄和跟蹤日程安排以及執行其他任務。在Windows系統上的多個Outlook版本中都發現了Heap Corruption漏洞，涵蓋了從Outlook 2010到最新的Outlook 2019以及Office 365 ProPlus的所有32/64位版本。該漏洞由格式錯誤的RWZ（郵件分類規則）文件觸發。當Outlook收到不正確的RWZ文件內容時，分配的堆內存不足並且缺少適當的邊界檢查，從而導致堆的越界寫入。

在本博客中，我將分享對此漏洞的詳細分析。

一、重現漏洞

要重現此漏洞，需要運行Microsoft Outlook，然後單擊「規則=>管理規則和警報=>選項=>導入規則」，並選擇導致Outlook崩潰的PoC文件。

圖1.重現漏洞

發生崩潰時，調用堆棧如下所示：

圖2.崩潰發生時的堆棧

二、漏洞分析

正如從調用堆棧中看到的那樣，崩潰發生在堆釋放時。由於我們現在無法確認釋放的堆塊有什麼問題，我們可以打開整頁堆來跟蹤有問題的堆塊。命令如下：

YOUR_WINDBG_INSATALL_LOCATIONgflags.exe /p /enable outlook.exe /full

可以看到如下返回結果，表明它已成功執行。

圖3.完整頁面堆已成功打開

完成此操作後，我們可以再次打開Outlook並選擇PoC文件以便在發生崩潰時監視新堆棧：

圖4.打開Full Page Heap時的崩潰位置

現在我們可以看到ECX指向的非零內存地址是不可讀的，並且在將數據寫入該內存地址時會發生異常。因此將數據寫入未分配（或釋放）的內存的可能性很高。可以通過檢查內存頁面分配來驗證這個預測，我們可以看到內存仍然具有Reserve屬性。這是截圖：

圖5.保留的內存頁面

我們現在需要弄清楚程序為什麼要將數據寫入未使用的內存頁面。通過靜態分析，我們可以看到ECX的值來自EDI，並且在調用MAPIAllocateBuffer之後正在修改EDI，如下面的屏幕截圖所示：

圖6. ECX值的來源

通過靜態分析，我們了解到函數MAPIAllocateBuffer是RtlAllocateHeap的封裝函數，它進行檢查確保請求的堆大小參數不大於0x7FFFFFF7。這意味著它不是負的。但是，在此情形之下，它不會檢查0是否可以用作參數。並且因為實際分配的堆大小比請求的堆大小多8個位元組，這8個位元組用0x0000000001000010填充。之後，MAPIAllocateBuffer在這8個位元組後返回堆地址。因此，調用MAPIAllocateBuffer後的EDI值為8 +從RtlAllocateHeap接收的分配堆地址。截圖如下：

圖7.檢查分配的堆的大小

圖8.分配額外的8個位元組

從上面的靜態分析中，我們可以粗略地預測在Reserve堆中寫入數據很大概率是由整數溢出引起的。結合調試，我們發現調用MAPIAllocateBuffer的堆大小參數確實為0。但是，由於MAPIAllocateBuffer請求分配大小為0 + 8 = 8的堆，因此RtlAllocateHeap不會返回錯誤並成功返回正確的堆地址。但是，MAPIAllocateBuffer使用這8個位元組寫入0x0000000001000010，然後向用戶返回無效的堆尾地址。截圖如下：

圖9.只減少一個位元組，但堆是正確的

接下來，我們需要弄清楚為什麼請求的堆大小的值會變為0。結合調試和靜態分析，我們發現值0來自當前函數的參數：arg_4（eax = arg_4 * 4 + 4）。但是，當調用當前函數時，arg_4的值不是傳入參數的值，這意味著此函數會修改arg_4。通過調試我們可以看到更改是在子函數sub_65F7DA中完成的。截圖如下：