各浏览器抗uaf机制

今年中旬，微软针对旗下ie浏览器中大量出现的uaf漏洞，对ie浏览器的安全机制进行了一个大幅度的升级，其中主要体现为隔离堆及延迟释放两个机制，顿时又将uaf漏洞的利用向上提升了一个大坎，
但是类似的对抗uaf的机制在firefox以及chrome中已有类似的实现，本文就各个浏览器的该机制做一个小总结。

ie
Isolated Heap(隔离堆)
dom树对象以及supporting对象的对象空间在隔离的堆中被分配，该堆位于默认堆的低地址，该堆的句柄保存于一个全局变量中，对于该堆的内存分配涉及到两个函数
_MemIsolatedAlloc
_MemIsolatedAllocClear
其中分配时会通过对HeapAlloc函数中标记参数HEAP_ZEAR_MEMORY的设置，使的新分配的对象空间清零，但是该机制只是针对部分的对象使用（好在只是部分）。

delay free（延迟释放）
struct MemoryProtector{
void * BlockArray； //指向一个结构体数组，该结构体保存了所有被延迟释放元素的大小和地址
DWORD TotalSize; //此值就是所有被延迟释放的对象的总大小，即阀值。
DWORD NumberOfUsed;
bool Sorted; //标记暂时不知道具体含义
DWORD unknow;
DWORD unKnow;
DWORD StackHighAddress;
DWORD EnableReclaim;
}
具体的实现函数
MemoryProtection::CMemoryProtector::ProtectedFree
所谓的延迟释放就是指浏览器中释放的对象在释放时并不是真正意义上的释放，该函数会将这些无用对象（首先清零），并将这些无用的对象连接到st_ProtecFreeManageHeap对象中，直到所有延迟对象的
总大小到达一定阀值是在进行处理（此时依赖于TotalSize的值）。当所有的延迟对象到达阀值之后也并没有马上进行释放操作,而是调用了一下两个函数
MemoryProtection::CMemoryProtector::MarkBlocks
MemoryProtection::CMemoryProtector::ReclaimUnmarkeBlock
其中在函数MarkBlocks中会扫描栈中是否存在对这些延迟释放对象的引用，如果存在则对该元素进行标记。
在函数ReclaimUnmarkeBlock中完成释放（有标记的不释放）。

firefox
Frame Poisoning机制
目标：一些在页面渲染中常用框架型的对象
作用：该类对象在释放的时候其内存空间会被chosenpattern（该分配对象会被回收至freelist，并优先分配给类型相同的对象，提高了占位难度）
分配的时候支持三种类型的分配
By object ID
By frame ID
By size
对象A在空间分配的时候（此时会从freelist中优先获取一个空闲的内存空间）确保该分配的空间来自于一个与A对象的类型一致的对象，当freelist中没有类型一致的空间是才会创建自动创建一段空间返回。

chrome
PartitionAlloc机制
该机制管理堆的时候将对分成四个类型，依据申请对象的类型依次从中分配内存空间。
ObjectModelPartition：保存了所有node类的子类，也大致可以理解为就是DOM tree
RenderingPartion：保存了所有渲染树的对象
BufferPartition：保存了Web Template Framework的对象，同时也包含了一些js的类型，比如arraybuffer和stringlmpl
General Partition
在这四个分区中，又依据分配的对象的大小再次进行了分区，导致攻击者在站位时必须选择与可利用对象属于同一分类（并且在同一类型中又要满足同大小的分配）

其中每个分区又依照以下的规则进行划分，并在其中做了一些手脚。
从小到大，以此包含
bockets< superpages（0x200000）< extents < partition。
bockets 依照请求的大小分配出去
每个superpages的开始都有一个guard area的域用于检测攻击者的一系列连续读写操作，也就是说哪怕你费尽心思的构造了可全内存都写的数组，但是数组所在的内存空间中却插上了一堆检测域（guard area）。
superpages
　　metadata
　　dataarea（0x1f8000）
　　guard area(reserves,inaccessible page)