初探UAF漏洞（2）

漏洞分析

申请空间

AllocateUaFObjectNonPagedPool函数向上跟，发现IOCTL为2236435时调用AllocateUaFObjectNonPagedPoolIoctlHandler函数

该函数直接调的就是AllocateUaFObjectNonPagedPool

进入AllocateUaFObjectNonPagedPool后，可以看到通过ExAllocatePoolWithTag申请一个大小为0x58大小空间的内存，并将该内存返回的指针赋值给全局变量g_UseAfterFreeObjectNonPagedPool

实际上0x58大小正好是一个结构体_USE_AFTER_FREE_NON_PAGED_POOL

释放空间

向上跟踪FreeUaFObjectNonPagedPool,看谁调用了他

IOCTL为2236443时调用FreeUaFObjectNonPagedPoolIoctlHandler函数

同样FreeUaFObjectNonPagedPoolIoctlHandler仅仅调用了FreeUaFObjectNonPagedPool

通过ExFreePoolWithTag释放g_UseAfterFreeObjectNonPagedPool指向的空间

数据载入

该函数IOCTL为2236511

将用户模式传入UserFakeObject指向内容拷贝给内核中申请的内存。

注意这里申请的大小也是0x58，那么试想一种情景：

如果通过AllocateUaFObjectNonPagedPool申请了一块内存，并通过FreeUaFObjectNonPagedPool释放这块内存，但并没有将g_UseAfterFreeObjectNonPagedPool指针指向null，此时通过AllocateFakeObjectNonPagedPoolNx再次申请内存，那么v1就有可能重新指向一开始申请的内存，即v1和g_UseAfterFreeObjectNonPagedPool指向同一块内存，而此时v1可控，由三环UserFakeObject传入，那么此时如果有个函数可以执行g_UseAfterFreeObjectNonPagedPool则可造成UAF漏洞。

正好有这样一个函数UseUaFObjectNonPagedPool，能执行g_UseAfterFreeObjectNonPagedPool指针。