UAF漏洞學習

　　產生緣由：

　　UAF漏洞的成因是一塊堆內存被釋放了以後又被使用。又被使用指的是：指針存在（懸垂指針被引用）。這個引用的結果是不可預測的，由於不知道會發生什麼。因爲大多數的堆內存其實都是C++對象，因此利用的核心思路就是分配堆去佔坑，佔的坑中有本身構造的虛表。

　　分析方式：

　　觸發UAF漏洞須要一系列的操做，而不是像傳統的溢出一個操做就會致使溢出。IE瀏覽器中的DOM標籤由一個對象來表示，而且IE自帶的類中存在了一些對象管理的方法。分析UAF漏洞的要點在於搞清楚對象是在哪裏被分配的，哪裏被釋放的，哪裏被重用的。UAF的異常觸發點是很明顯的，就是對已釋放的對象進行操做致使的異常。因此異常點也就是重用點。而因爲是對對象的操做，能夠列出這個對象的全部方法，找出分配和釋放的方法，對其下斷來分析究竟是怎麼發生的UAF過程。

　　首先要說明2個概念：

1. 　　懸垂指針：懸垂指針是指一類不指向任何合法的或者有效的（即與指針的含義不符）的對象的指針。好比一個對象的指針，若是這個對象已經被釋放或者回收可是

 指針沒有進行任何的修改仍然執行已被釋放的內存，這個指針就叫作懸垂指針

　　2.　　UAF漏洞：Use-After-Free是一種內存破壞漏洞，簡單的說，漏洞的緣由是使用了懸垂指針。

　　

 

 

　　IE瀏覽器DOM樹的實現原理，這是根本

　　常見的與UAF漏洞配合使用的就是堆噴射了，堆噴射的思想就是分配大量內存，增大靶子的面積。使EIP能跳進分配的內存中。而分配的內存中又充滿了滑板指令，只要命中了滑板指令就能夠命中Shellcode。爲了利用UAF漏洞，要理解漏洞觸發的時機，涉及的對象等。而後經過Js來精心佈局內存並控制EIP的控制權。

　　注意的是，對於UAF漏洞來講，調試器捕獲的異常每每都不是漏洞發生的第一現場，因此通常都要使用gflags開啓PageHeap和UST，命令以下（windbg自帶gflags工具）

gflags.exe /i 程序名.exe +hpa +ust

　　這樣調試器就會定位到最早出錯的位置

　　此外有以下技巧：

• 在IDA裏查找函數後，在Windbg裏下斷。若是知道了一個對象的一個方法殊不知道怎麼斷下它，就用IDA加載符號，搜索方法。說不定就能找到對應的C++函數名。
• 1.打開poc文件後，出現crash就是對象被重用，根據crash地址來找到重用的對象起始地址。
• 2.對對象起始使用!heap -p -a 地址。就能夠得到這個對象的分配信息，由回溯還能夠知道是什麼函數分配的
• 3.對分配函數下斷來達到分配現場
• 4.若是!heap -p -a 地址 後獲得的是釋放的回溯，那麼怎麼知道分配函數呢？答案是在釋放函數上下斷，而後斷到那裏時使用！heap -p -a 地址獲得的就是分配的回溯了，計劃通。
• 在回溯中，所謂的分配函數通常就是RtlAllocateHeap的上層。而釋放函數通常就是FreeHeap的上層（或者RtlFreeHeap?）

 

一個頁面包含CMarkup對象來表示頁面的結構或者DOM數。CMarkup對象包含一個指向根CElement對象的指針。CElement對象是不少實體類的父類。在圖1中Javascript對象e_1和e_2是繼承自CElement的CObjectElement對象。CElement對象存在一個指向CTreeNode對象的指針。CTreeNode對象還存在一個與CElement對象相關的指針。CTreeNode的對象有一對指向CTreePos對象的指針。

那爲何一個CTreePos是必須的？由於IE使用了伸展樹算法(Splay Tree)來操控DOM樹。在伸展樹算法樹中CTreePos對象做爲一個節點。CMarkupPointer對象表明CMarkup對象中的一個地址。因此CMarkupPointer對象有一個指向CTreePos對象的指針來表明他的地址。CMarkup對象有不少與UAF相關的狀態。

l 嵌入狀態：這意味着CMarkupPointer建立了CTreePos對象並加入了伸展樹中。

l 非嵌入狀態：這意味着CMarkupPointer把CTreePos對象移出伸展樹並釋放。

下圖展現了伸展樹的交互過程：

 

 經過