類型混淆漏洞一般是將數據類型A當做數據類型B來解析引用，這就可能導致非法訪問數據從而執行任意代碼。
本文通過IE類型混淆漏洞實例和Word類型混淆漏洞實例進行分析，來學習理解類型混淆漏洞原理。
實例一：IE/Edge類型混淆漏洞（CVE-2017-0037）
漏洞原因：函數處理時，沒有對對象類型進行嚴格檢查，導致類型混淆。
分析環境： Win7、IE11
分析工具： Windbg、od、IDA Pro
在PoC中定義了一個table，標籤中定義了表id爲th1，在boom()中引用，然後是setInterval設定事件。
漏洞成因分析：
運行PoC，用OD或Windbg附加並加載運行，出現崩潰，如下圖
從崩潰點可以看到eax作爲指針，引用了一個無效地址，導致崩潰，而上一條指令是一個call，如下
這個無效的返回值來自這個call，此時我們進行逆推，在這個call處下斷點，
ecx作爲參數，存放的對象是一個Layout::FlowItem::`vftable虛表
這個值會在Readable函數中引用，如下圖
這裏讀取虛表中+4的值，爲0時this指針賦值v1，隨後v1+16後返回，因此，Layout::FlowItem::`vftable所屬指針的這個情況是正常的，函數會正常返回進入後續處理邏輯。
讓程序繼續運行，會再次調用該函數，此時ecx並不是一個虛表對象，而是一個int
Array對象，這裏我們可以通過條件斷點來跟蹤兩個對象的創建過程，重點關注兩個對象創建的函數，一個是FlowItem::`vftable對應的虛表對象，另一個是引發崩潰的int
Array對象。這兩個函數的返回值，也就是eax寄存器中存放的指向這兩個創建對象的指針。
通過條件斷點，輸出每一次int Array object創建的對象信息
通過跟蹤可以看到第一次調用Readable函數時ecx是一個正常的FlowItem對象，而第二次調用的時候ecx是一個int
Array Object。Layout::Patchable
>::Readable函數是處理虛表對象的函數，由於boom()函數中引用th1.align導致Readable函數得到第二次引用，由於沒有進行對象屬性檢查，導致第二次調用時將table對象傳入，最終發生類型混淆崩潰。
分析利用關鍵點
首先我們分析崩潰點上下文，通過流程走向看看是否有可利用的點，
在判斷eax返回值不等於0後，會繼續往下調用Readable函數，且eax會連續引用，後面看到一個call edi，這是一個虛函數，如果我們能控制edi就有可能在這裏達到代碼執行的效果。其中有一個控制流保護機制CFG(call __guard_check_icall_fptr)，Win7系統未開啓所以這裏不用考慮pass。
edi是由ecx(Array Object)傳遞過來的，通過修改th1對象中的width值爲2000000，允許我們將EAX的值移動到堆噴射中的受控內存位置。
PoC中設置eip爲0x41414141
這裏eax=0bebc2d8，我們的受控位置爲0Xbebc200=（2000000*100），在可控範圍。
EIP被設置爲0x41414141，由於加載的所有模塊均啓用了ASLR，目前仍沒有繞過的方法。
實例二：Word類型混淆漏洞（CVE-2015-1641）
漏洞原因：
Word在解析docx文檔的displacedByCustomXML屬性時未對customXML對象進行驗證，導致可以傳入其他標籤對象進行處理，造成類型混淆。
分析環境： 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分析結果爲4個文件，分離保存。
在樣本中提取第三個OLE，構造成rtf文件（上圖爲文件前半部分截圖），打開該文件後出錯，如下圖，可以看到故障模塊爲wwlib.dll，異常偏移爲0x9d30。
運行word，用windbg附加word進程，再打開rtf文件，異常出現在wwlib模塊中的0x5c4a9d30，代碼爲mov esi,dword ptr [ecx]，崩潰原因是[ecx]引用到無效地址。
這裏ecx=0x7c38bd50，指向何處? 接下來分析保存出來的ole文件，解壓後在資源文件“document.xml”中發現ecx的值正是smarttTag標籤的element的屬性值。
smartTag是一個智能標籤，可針對人名、日期、時間、地址、電話號碼等進行智能識別並允許用戶執行特定操作的標籤，displacedByCumtomXml屬性表示此處要替換爲另一個customxml標籤，樣本作者在smartTag的element中構造了0x7c38bd50，Word在解析docx文檔處理displacedByCustomXML屬性時未對customXML對象進行驗證，所以能傳入smartTag標籤對象。
由於是單獨加載觸發漏洞OLE引用到無效地址，因爲這個地址位於” MSVCR71.DLL”模塊中，而這個DLL正是通過第一個OLE對象“otkloadr.wRAssembly.1”引入的。將第一個OLE對象：{\object\objocx{\*\objdata180115000002000000160000006f746b6c6f6164722e5752417373656d626c792e3100000000000000000001000000400105000000000000}}，添加到觸發漏洞的OLE前面，構建成RTF運行,再通過Windbg下條件斷點，這裏先記錄下crash發生的時候“0x7c38bd50 “所在的模塊地址，通過它來下條件斷點：
0x7C38BD50是smartTag標籤的element值，4294960790（0xFFFFE696）是moveFromRangeStart的值，隨後對這兩個值進行計算得到一個地址0x7C38BD74。計算過程如下：
第二個smartTag，smartTag標籤的element值此時爲0x7C38BD68，moveFromRangeStart的值爲0x7C376FC3（十進制爲2084007875），計算出的地址爲0x7C38A428，最後通過memcpy函數將0x7C376FC3覆蓋到地址0x7C38A428中，在調試器可以看到，0x7C38A428爲虛表指針：
接着往下執行，
會先經過一大片地址爲“7C342404”的“ret”，然後進入ROP鏈，再往後就是shellcode。
將id爲1的OLE解壓後，
在解壓目錄的“activeX1.bin“中看到用來堆噴的數據塊：nop指令上面的是ROP鏈，heapspary前會使用大量地址爲0x7c342404 的ret-sled，
以上兩實例分析文章在網上較多，這裏只做一個淺析，不做深入分析。
原創文章轉載請註明來源：四維創智***實驗室