這篇文章將為大家詳細講解有關怎么對Microsoft Outlook漏洞的深入分析,文章內(nèi)容質(zhì)量較高,因此小編分享給大家做個參考,希望大家閱讀完這篇文章后對相關知識有一定的了解。
創(chuàng)新互聯(lián)建站專注于企業(yè)全網(wǎng)營銷推廣、網(wǎng)站重做改版、平城網(wǎng)站定制設計、自適應品牌網(wǎng)站建設、H5頁面制作、成都做商城網(wǎng)站、集團公司官網(wǎng)建設、成都外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應式網(wǎng)頁設計等建站業(yè)務,價格優(yōu)惠性價比高,為平城等各大城市提供網(wǎng)站開發(fā)制作服務。
MicrosoftOutlook是微軟Office套件中的一個組件,它可以用來發(fā)送和接收電子郵件,管理聯(lián)系人,記錄和跟蹤日程計劃,或執(zhí)行其他任務。近期,研究人員在Outlook 2010至Outlook 2019版本以及Office 365 ProPlus中發(fā)現(xiàn)了一個堆崩潰漏洞,Windows平臺下的32/64版本均會受到該漏洞影響。攻擊者可使用惡意RWZ文件來觸發(fā)該漏洞,當Outlook收到惡意RWZ文件內(nèi)容時,它只會分配少量堆內(nèi)存,并且缺少恰當?shù)倪吔鐧z測,最終導致堆內(nèi)存越界寫入。
為了復現(xiàn)該漏洞,我們需要運行Microsoft Outlook,然后點擊“規(guī)則=>管理規(guī)則&警報=>選項=>導入規(guī)則”,選擇可以觸發(fā)Outlook崩潰的PoC文件。
下面給出的就是發(fā)生崩潰時的棧調(diào)用情況:
我們可以從棧調(diào)用數(shù)據(jù)中看到,當堆內(nèi)存被釋放時就發(fā)生程序崩潰了。因為我們無法判單堆釋放時發(fā)生了什么情況,所以我們需要打開完整的堆內(nèi)存頁表來跟蹤堆內(nèi)存的數(shù)據(jù)變化,命令如下:
YOUR_WINDBG_INSATALL_LOCATION\gflags.exe/p /enable outlook.exe /full
上述命令返回的結(jié)果如下,表明命令已成功執(zhí)行了。
接下來,我們再次打開Outlook,選擇PoC文件并監(jiān)控崩潰發(fā)生時新的??臻g情況:
現(xiàn)在我們可以看到,ECX指向的非0內(nèi)存地址時不可讀的,并且在向這個內(nèi)存地址寫入數(shù)據(jù)時會發(fā)生異常,很有可能是因為程序在嘗試向未分配(或未釋放)的內(nèi)存地址寫入數(shù)據(jù)。我們可以通過檢測內(nèi)存頁分配情況來驗證這種猜想,此時我們會看到內(nèi)存仍然擁有Reserve屬性:
現(xiàn)在我們需要弄清楚,為什么程序會向未使用的內(nèi)存頁寫入數(shù)據(jù)。通過靜態(tài)分析,我們可以看到ECX的值來自于EDI,而EDI貌似會在程序調(diào)用MAPIAllocateBuffer后被修改:
靜態(tài)分析的結(jié)果表明,MAPIAllocateBuffer函數(shù)其實是RtlAllocateHeap的封裝函數(shù),而這個函數(shù)會確保請求的內(nèi)存大小參數(shù)不會超過0x7FFFFFF7。但是,它無法檢測該參數(shù)的值是否為0,因為實際分配的堆大小為8字節(jié),超過了請求的堆大小,這8個字節(jié)填充值為0x0000000001000010。接下來,MAPIAllocateBuffer會返回這8個字節(jié)后面的堆地址。因此,在調(diào)用MAPIAllocateBuffer之后EDI的值為8 + 分配的堆地址(來自RtlAllocateHeap):
根據(jù)上面的靜態(tài)分析結(jié)果,我們可以大致判斷導致漏洞出現(xiàn)的原因為整型溢出問題。通過調(diào)式后我們發(fā)現(xiàn),調(diào)用MAPIAllocateBuffer時的堆大小參數(shù)為0,因為MAPIAllocateBuffer請求分配的堆大小為0+8=8,此時RtlAllocateHeap不會返回錯誤,而是返回正確的堆地址。MAPIAllocateBuffer會使用這8字節(jié)來寫入地址0x0000000001000010,然后把無效的內(nèi)存地址返回給用戶:
接下來,我們需要弄清楚請求的堆大小值為什么會變成0。原來,0值來自于當前的一個函數(shù)參數(shù):arg_4(eax = arg_4 * 4 + 4)。但是,當這個函數(shù)被調(diào)用時,arg_4的值并非傳遞進來的參數(shù)值,這也就意味著arg_4的值被修改了。分析后我們發(fā)現(xiàn),罪魁禍首是其子函數(shù)sub_65F7DA:
在對子函數(shù)sub_65F7DA進行分析后,我們發(fā)現(xiàn)它也是一個封裝函數(shù)。原來,這個函數(shù)是ReadFile,而arg_4得值實際上來自于PoC文件:
調(diào)試結(jié)果表明,arg_4讀取到的文件內(nèi)容為0xFFFFFFFF,因此堆內(nèi)存的分配大小就是0xFFFFFFFF * 4 + 4 = 0(整型溢出)。然而,程序并不會檢測這種錯誤,最終導致了越界寫入的情況出現(xiàn):
在PoC文件中我們可以看到,并不存在0xFFFFFFFF這個值:
將其修改為0xAABBCCDD后再次進行調(diào)試,我們就可以證實溢出就是由這4個字節(jié)造成的:
在安裝了修復補丁之后,我們對前后的程序代碼進行了對比,我們發(fā)現(xiàn)補丁增加了對請求分配堆內(nèi)存大小的驗證:
因此,廣大用戶請盡快安裝更新補丁以防止攻擊者利用該漏洞實施攻擊。
MS.Outlook.CVE-2018-8587.Remote.Code.Execution
關于怎么對Microsoft Outlook漏洞的深入分析就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
本文標題:怎么對MicrosoftOutlook漏洞的深入分析
本文地址:http://jinyejixie.com/article46/igojeg.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供面包屑導航、微信小程序、服務器托管、搜索引擎優(yōu)化、移動網(wǎng)站建設、外貿(mào)網(wǎng)站建設
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)