產生原因：
UAF漏洞的成因是一塊堆內存被釋放了之后又被使用。又被使用指的是：指針存在（懸垂指針被引用）。這個引用的結果是不可預測的，因為不知道會發生什么。由於大多數的堆內存其實都是C++對象，所以利用的核心思路就是分配堆去占坑，占的坑中有自己構造的虛表。
分析方式：
觸發UAF漏洞需要一系列的操作，而不是像傳統的溢出一個操作就會導致溢出。IE瀏覽器中的DOM標簽由一個對象來表示，並且IE自帶的類中存在了一些對象管理的方法。分析UAF漏洞的要點在於搞清楚對象是在哪里被分配的，哪里被釋放的，哪里被重用的。UAF的異常觸發點是很明顯的，就是對已釋放的對象進行操作導致的異常。所以異常點也就是重用點。而由於是對對象的操作，可以列出這個對象的所有方法，找出分配和釋放的方法，對其下斷來分析到底是怎么發生的UAF過程。
首先要說明2個概念：
- 懸垂指針：懸垂指針是指一類不指向任何合法的或者有效的（即與指針的含義不符）的對象的指針。比如一個對象的指針，如果這個對象已經被釋放或者回收但是
指針沒有進行任何的修改仍然執行已被釋放的內存，這個指針就叫做懸垂指針
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對象移出伸展樹並釋放。
下圖展示了伸展樹的交互過程：
通過