国产精品资源网在线观看,国产美女主播,国产精品1024,国产一级做a爱片久久毛片a,欧美大片在线,亚洲一区二区三区免费

類型混淆漏洞一般是將數(shù)據(jù)類型A當(dāng)做數(shù)據(jù)類型B來解析引用，這就可能導(dǎo)致非法訪問數(shù)據(jù)從而執(zhí)行任意代碼。
 
本文通過IE類型混淆漏洞實例和Word類型混淆漏洞實例進行分析，來學(xué)習(xí)理解類型混淆漏洞原理。
 
實例一：IE/Edge類型混淆漏洞（CVE-2017-0037）
 
漏洞原因：函數(shù)處理時，沒有對對象類型進行嚴(yán)格檢查，導(dǎo)致類型混淆。
分析環(huán)境： Win7、IE11
分析工具： Windbg、od、IDA Pro

在PoC中定義了一個table，標(biāo)簽中定義了表id為th1，在boom()中引用，然后是setInterval設(shè)定事件。
 
漏洞成因分析
 
運行PoC，用OD或Windbg附加并加載運行，出現(xiàn)崩潰，如下圖


 
從崩潰點可以看到eax作為指針，引用了一個無效地址，導(dǎo)致崩潰，而上一條指令是一個call，如下

 
這個無效的返回值來自這個call，此時我們進行逆推，在這個call處下斷點，

 
ecx作為參數(shù)，存放的對象是一個Layout::FlowItem::`vftable虛表

 
這個值會在Readable函數(shù)中引用，如下圖


這里讀取虛表中+4的值，為0時this指針賦值v1，隨后v1+16后返回，因此，Layout::FlowItem::`vftable所屬指針的這個情況是正常的，函數(shù)會正常返回進入后續(xù)處理邏輯。
 

讓程序繼續(xù)運行，會再次調(diào)用該函數(shù)，此時ecx并不是一個虛表對象，而是一個int Array對象，這里我們可以通過條件斷點來跟蹤兩個對象的創(chuàng)建過程，重點關(guān)注兩個對象創(chuàng)建的函數(shù)，一個是FlowItem::`vftable對應(yīng)的虛表對象，另一個是引發(fā)崩潰的int Array對象。這兩個函數(shù)的返回值，也就是eax寄存器中存放的指向這兩個創(chuàng)建對象的指針。


 
通過條件斷點，輸出每一次int Array object創(chuàng)建的對象信息


通過跟蹤可以看到第一次調(diào)用Readable函數(shù)時ecx是一個正常的FlowItem對象，而第二次調(diào)用的時候ecx是一個int Array Object。Layout::Patchable >::Readable函數(shù)是處理虛表對象的函數(shù)，由于boom()函數(shù)中引用th1.align導(dǎo)致Readable函數(shù)得到第二次引用，由于沒有進行對象屬性檢查，導(dǎo)致第二次調(diào)用時將table對象傳入，最終發(fā)生類型混淆崩潰。
 
分析利用關(guān)鍵點
首先我們分析崩潰點上下文，通過流程走向看看是否有可利用的點，

在判斷eax返回值不等于0后，會繼續(xù)往下調(diào)用Readable函數(shù)，且eax會連續(xù)引用，后面看到一個call edi，這是一個虛函數(shù)，如果我們能控制edi就有可能在這里達到代碼執(zhí)行的效果。其中有一個控制流保護機制CFG(call __guard_check_icall_fptr)，Win7系統(tǒng)未開啟所以這里不用考慮pass。

 
edi是由ecx(Array Object)傳遞過來的，通過修改th1對象中的width值為2000000，允許我們將EAX的值移動到堆噴射中的受控內(nèi)存位置。


PoC中設(shè)置eip為0x41414141
 

這里eax=0bebc2d8，我們的受控位置為0Xbebc200=（2000000*100），在可控范圍。
 

EIP被設(shè)置為0x41414141，由于加載的所有模塊均啟用了ASLR，目前仍沒有繞過的方法。
 
實例二：Word類型混淆漏洞（CVE-2015-1641）
 
漏洞原因：Word在解析docx文檔的displacedByCustomXML屬性時未對customXML對象進行驗證，導(dǎo)致可以傳入其他標(biāo)簽對象進行處理，造成類型混淆。
 
分析環(huán)境： Win7、Word2007
分析工具： Windbg、od、oletools、notepad++、WinHex
樣本：https://github.com/houjingyi233/office-exploit-case-study/blob/master/CVE-2015-1641/8bb066160763ba4a0b65ae86d3cfedff8102e2eacbf4e83812ea76ea5ab61a31.bin.gz

首先解壓樣本并改后綴名為doc，用oletools的rtfobj分析結(jié)果為4個文件，分離保存。
 

在樣本中提取第三個OLE，構(gòu)造成rtf文件（上圖為文件前半部分截圖），打開該文件后出錯，如下圖，可以看到故障模塊為wwlib.dll，異常偏移為0x9d30。

運行word，用windbg附加word進程，再打開rtf文件，異常出現(xiàn)在wwlib模塊中的0x5c4a9d30，代碼為mov esi,dword ptr [ecx]，崩潰原因是[ecx]引用到無效地址。
 

這里ecx=0x7c38bd50，指向何處? 接下來分析保存出來的ole文件，解壓后在資源文件“document.xml”中發(fā)現(xiàn)ecx的值正是smarttTag標(biāo)簽的element的屬性值。
 

smartTag是一個智能標(biāo)簽，可針對人名、日期、時間、地址、電話號碼等進行智能識別并允許用戶執(zhí)行特定操作的標(biāo)簽，displacedByCumtomXml屬性表示此處要替換為另一個customxml標(biāo)簽，樣本作者在smartTag的element中構(gòu)造了0x7c38bd50，Word在解析docx文檔處理displacedByCustomXML屬性時未對customXML對象進行驗證，所以能傳入smartTag標(biāo)簽對象。
 

由于是單獨加載觸發(fā)漏洞OLE引用到無效地址，因為這個地址位于” MSVCR71.DLL”模塊中，而這個DLL正是通過第一個OLE對象“otkloadr.wRAssembly.1”引入的。將第一個OLE對象：{\object\objocx{\*\objdata180115000002000000160000006f746b6c6f6164722e5752417373656d626c792e3100000000000000000001000000400105000000000000}}，添加到觸發(fā)漏洞的OLE前面，構(gòu)建成RTF運行,再通過Windbg下條件斷點，這里先記錄下crash發(fā)生的時候“0x7c38bd50 “所在的模塊地址，通過它來下條件斷點：

 
0x7C38BD50是smartTag標(biāo)簽的element值，4294960790（0xFFFFE696）是moveFromRangeStart的值，隨后對這兩個值進行計算得到一個地址0x7C38BD74。計算過程如下：


 
第二個smartTag，smartTag標(biāo)簽的element值此時為0x7C38BD68，moveFromRangeStart的值為0x7C376FC3（十進制為2084007875），計算出的地址為0x7C38A428，最后通過memcpy函數(shù)將0x7C376FC3覆蓋到地址0x7C38A428中，在調(diào)試器可以看到，0x7C38A428為虛表指針：

 
接著往下執(zhí)行會先經(jīng)過一大片地址為“7C342404”的“ret”，然后進入ROP鏈，再往后就是shellcode。

 
將id為1的OLE解壓后，在解壓目錄的“activeX1.bin“中看到用來堆噴的數(shù)據(jù)塊：nop指令上面的是ROP鏈，heapspary前會使用大量地址為0x7c342404 的ret-sled，

以上兩實例分析文章在網(wǎng)上較多，這里只做一個淺析，不做深入分析。