该漏洞为Pwn2014上Siberas团队公布的提权漏洞，此漏洞出现在AFD.sys文件中，POC将以DoubleFree的形式触发漏洞，利用思路是通过将DoubleFree漏洞转换为UAF来构造Exploit。

本文的调试环境为Windows 7 SP1 x86，通过双虚拟机双机调试。这和参考1中漏洞发现者的环境不同， 因此有些细节也不一样（例如漏洞发现者PDF中提到的内存为NonPagedPoolNx， 而我们的是NonPagePool）。

本漏洞成因简单、利用思路也非常经典， 因此极为适合新手作为漏洞学习的入门洞。

漏洞触发现场如下：

由上述第69行可知，为IoFreeMdl在释放8757da60时出现Double Free错误导致。到这里，很自然会产生如下几个疑问：

为什么会DoubleFree？ <--- 终极问题
8757da60这个MDL是在哪里分配的？
第一次是在哪里释放的？
第二次是在哪里释放的？

其中，第四个问题可以立刻解答，因为当前现场即是第二次释放现场。

为了解答上面的第一个终极问题，我们要先搞清楚问题2、3。

（注意：由于该漏洞属于内核级漏洞，因此调试过程中需要不停重启，因此下文中截图涉及内存地址的地方会有差异。）

既然是寻找Mdl的内存分配，首先看一眼IoAllocateMdl的调用交叉引用：

Emmm……打消了一个一个找的念头。

然后想利用条件断点在IoAllocateMdl返回8757da60这个地址时下断，发现一旦下了断点，这个地址会发生改变——似乎进入死胡同了（后来发现其实多断几次总是能断到的）。

这里网上大部分的分析文章都是从POC的两次DeviceIOControl着手分析。本文本着自虐的原则，笔者会假设我们并不知道POC的内容是什么，这次BugCheck只是漏洞挖掘的Fuzz环境中发现的一次内核级异常，我们将尽量尝试贴近真实的漏洞挖掘环境。

首先上IDA看一下出现异常的现场上下文是怎样的（注意，下图中已经加载了符号分析得到的数据结构）：

有的朋友可能好奇这些数据结构是如何分析得到的，在这里笔者只能告诉大家，通过对：AfdReturnTpInfo、AfdTransmitFile、AfdTliGetTpInfo可以得到如下关键结构：

然后看一眼出问题的struc_UnkObj->MdlAddress的交叉引用：

发现对MdlAddress成员的写操作，均在AfdTransmitFile函数中，然后在调试器中对几次MdlAddress赋值的地方下断点，中断后情况如下：

此时看一下eax的值（8757da60），发现和本文一开始异常发生时，IoFreeMdl尝试释放的值一致。说明我们找对分配内存的地方了：

其实简单一点来说就是，struc_TPInfo（v6和v7）由下图92行的AlfTliGetIpInfo构造并初始化、struc_TPInfo->struc_UnkObj（v50和v11）的MdlAddress成员由下图122行分配。

特别强调，由于内存通过上图92行的AfdTliGetTpInfo分配struc_TPInfo结构后，继续由122行的IoAllocateMdl分配了一个初始化的MDL内存，因此第一次IoFreeMdl释放这块内存时是不会蓝屏的（详见下一节分析）。

OK，既然目前内存何时分配已经清楚了，那我们来看一下这块内存第一次是何时释放的。

在WinDbg中下如下断点：

注意，这里有一个坑， 由于笔者是用64位WindDBG调试32位系统， 上面断点的值是64位的， 实测使用32位的值无法中断。

中断在如下地址：

发现调用路径是：

顺着调用链继续追踪：

发现上面这一片是异常处理代码，其try块位于 2C376 处， 而这个try块恰好包含我们上面跟踪到的分配Mdl内存的代码：

让我们来看一下上面30行地址的调试器现场：

结合IoAllocateMdl函数原型：

可知，此时程序正在尝试从0x13371337地址处分配一块0x0015fcd9大小的内存。而上图中8e38a49d地址处的call MmPorbeAndLockPages则尝试锁定刚刚分配的这块Mdl内存。

由于MDL中的内存地址是（我们控制，见下文分析）非法地址（0x13371337），从而导致MmProbeAndLockPage抛出异常，代码控制权转移到了异常控制块，从而需要依次调用：

也就是我们上面发现的异常调用链，至此第一次释放的原因已经分析清楚。

这时，需要注意一点：程序在调用IoFreeMdl之后，并没有将Mdl的指针设置为NULL，这里造成了悬挂指针的问题：

上图中，Entry为struc_TPInfo结构，由于这里并没有将struc_TPInfo->UnkObjArray的各个元素以及这个数组的各个子元素置NULL，当AfdReturnTpInfo最后释放Entry后，如果我们再次申请一个struc_TPInfo结构，则会得到保留了上次数据的一块内存，这里即产生了悬挂指针的问题。

这里笔者留个包袱，这个包袱将关联后文的构造POC一节。

通过分析释放时机可知，导致第一次内存释放的调用链：

CVE_2014_1767-> nt!DeviceIoControl -> afd!DispatchDeviceControl -> afd!AfdTransmitFile

通过回溯DeviceIoControl调用栈里面的信息，可知如下几个调用参数：

如下图：

（如果现在对比POC中填充的inbuf1，就可以看到上图中0x1326060+6*0x4位置处开始即为POC代码填充的数据了，此时可见上文中提到的非法地址：0x13371337）

上一节结尾提到

“如果我们再次申请一个struc_TPInfo结构，则会得到保留了上次数据的一块内存”

而通过“寻找内存分配时机”一节可知，AfdTliGetTpInfo负责分配一个struc_TPInfo结构。

那么AfdTliGetTpInfo函数有几次调用呢？看下图：

可见AfdTransmitPackets函数还会调用一次这个函数， 这也是本节我们将要分析的点。

我们继续在windbg中执行g命令让程序继续跑：

可以看到，第二次释放的调用链为：

此时我们如果再g一下，就会得到本文一开始一模一样的异常现场。

通过上面的调用链可以知道，第二次释放也是通过AfdReturnTpInfo最终触发的IoFreeMdl, 但是本次调用链上多了一个函数调用，即AfdTliGetTpInfo，让我们先看一下本函数的反汇编代码：

结构上和上次的现场差不多，都包含一个异常处理，通过上面的调用链可知一定是try块中触发了异常才有可能调用到AfdReturnTpInfo, 那我们在0002B88C的call处下断点看一下现场（0x10000为IDA加载afd.sys的基址）：

根据ExAllocatePoolWithQuotaTag的定义：

可知，目前正在尝试分配一块4294967280大小的内存（大约3.9Gb），由于被调试机器为32位且未开启PAE， 这种情况下必然会产生异常，因此会执行到0002B8A7处的AfdReturnTpInfo函数。

同时，需要注意，在0002B83C处从LookasideList内存处分配了一个struc_TPInfo后，并没有对struc_TPInfo->struc_UnkObj的MdlAddress成员初始化，因为在尝试调用ExAllocatePoolWithQuotaTag初始化该成员域时发生了异常（申请3.9Gb内存），从而执行流程跳转到了异常处理块的AfdReturnTpInfo处，但是AfdReturnTpInfo函数体中是会对struc_TPInfo->struc_UnkObj->MdlAddress执行释放操作的：

那么由于此时分配的struc_TPInfo结构使用的内存是上一次调用AfdTransmitFile异常后，释放（归还）给LookasidList的内存，由于本文一开始分析得到的悬挂指针的问题， 导致二次IoFreeMdl同一块内存。

这就是本文一开始终极问题的答案——为什么会DoubleFree。

同样埋一个包袱后文会用到。

让我们回到第二次释放时的调用现场：

通过对这个现场的回溯，我们可以得到第二次调用时的调用链如下：

CVE-2014-1767 -> nt!DeviceIoControl -> afd!AfdTransmitPackets

以及调用DeviceIoControl的参数信息：

上文中，有个细节没有提到（下面标红部分）：

知道了上述信息后，我们来覆盘一下DoubleFree产生的原因：

本小节涉及到上文中提到的两个包袱，通过对栈中数据的分析我们可以写出如下POC代码：

测试发现，并不能触发崩溃，通过上面漏洞的成因， 分别在afd!AfdTransmitFile与afd!AfdTransmitPackets下断点进一步分析，最终发现是在afd!AfdTransmitPackets中如下检查未通过导致的：

通过对内核中0xAFD2常数的追踪， 最终定位到这个常数的位置如下图：

接下来看一下winsock2模块是干啥用的， 了解一个模块的作用， 最快的方法莫过于通过其头文件了， 看一下其导出的函数：

发现一个老熟人， WSAStartup， 所以推测\\?\GLOBALROOT\Device\Afd是和socks函数相关的， 尝试把句柄替换为socks函数产生的句柄成功触发BSOD。

在知道正确的句柄类型之后， 我们就可以创建正确的设备对象来构造触发BSOD的POC了，下面POC中的端口， 只要是任意开放端口即可。

前文中，作者本着自虐的原则，刨根问底式的研究了很多“多余的东西”，但是作为一个Noob，完全自己去构造Expolit实在是过于难为作者了。因此，我们需要参考一下大佬们是如何构造Exploit的，我们需要通过大佬们的构造思路，来学习构造Exploit的技能——这部分技能恰好是我们所不具备的。

本文接下来的部分，主要是对《参考1》的理解以及《参考2》的解释，或者也可以理解为读书笔记。

通过上文的分析， 可知此漏洞的根本成因是DoubleFree， 如果我们能控制Free之后的这块内存，从而造成Object Manipulate的话，就可以控制任意内存——也就是将DoubleFree问题转换为UAF问题。

首先，我们从最朴素的目的来展开我们的思考。抛开所有问题不谈，漏洞利用最终的目标是什么？当然不是没有蛀牙，而是执行我们的ShellCode——那么我们将会面临两个问题：

针对第一个问题， 由于我们的程序已经装载到内存中执行了， 因此当内核运行在我们的Expoit进程空间时， 自然就可以访问到用户态的Shellcode地址，因此在Exploit中Shellcode其实就是个函数的地址而已(参考2)：

针对第二个问题， 我们知道Windows有很多的系统例程（比如SSDT里面的全都是）， 如果我们能替换掉某个例程的地址为我们的Shellcode地址，然后调用这个例程， 那CPU便会去执行我们的Shellcode代码。

当然， 此漏洞发现者使用的并不是SSDT里面的例程， 因为这个表里面的函数使用频率太高了，很容易被其他程序调用从而影响我们对漏洞的利用。 这里， 漏洞发现者盯上了漏洞利用届的老熟人、冷门调用的扛霸子：位于HalDispatchTable第二项的HaliQuerySystemInformation：

根据已知资料可知， 当我们调用NtQueryIntervalProfile时， 会导致内核态调用HalQuerySystemInformation函数。

所以， 如果我们将HalQuerySystemInformation函数的地址替换为我们Shellcode函数的地址， 然后调用NtQueryIntervalProfile， 我们的Shellcode便会的到执行。

那么， 新的问题又出现了：

根据上一节的分析可知 HalQuerySystemInformation 位于 HalDispatchTable+0x004 的位置， 好消息是 HalDispatchTable 在ntoskrnl.exe中是导出的：

获取一个导出的符号地址， 在R3中使用 LoadLibrary + GetProcAddress 的经典组合就可以搞定了， 唯一需要注意的是需要根据ntoskrnl.exe在内核中实际加载的基址重新计算一下导出名称的地址(参考2)：

OK， 现在我们知道了HalDispatchTable的地址， 我们下一步只需要向 HalDispatchTable+0x004 位置处写入我们Shellcode函数地址就可以了——可是我们如何写呢？ 接下来让我们回答上一节的问题：

“在获取到HalDispatchTable中地址后， 如何向这个地址写入我们Shellcode的地址”

Windows有一个很有意思的设计，为了管理内核对象， Windows提供了很多配套函数， 这些函数都是成组出现的， 其基本形式为： NtCreateXXX/NtQueryInformationXXX/NtSetInformationXXX。这三类函数一般用于创建内核对象或查询/设置该内核对象的信息。

如果要尝试构造任意地址写， NtSetInformationXXX系列函数是个不错的选择， 而漏洞发现者选取的内核对象为WorkerFactory， 即“受害”函数是NtSetInformationWorkerFactory， 让我们先来理解一下这个函数（仅列出重要部分）：

从函数的反汇编代码来看， 我们可以将4个字节的数据写到受控地址处， 地址的控制是通过WorkerFactory对象+0x10处的成员值间接计算得出的。 这里的几个要点为：

所以， Exploit中构造的写原语代码为(参考2)：

通过上面的写原语代码可知，我们是通过构造恶意的WorkerFactory对象实现的。然而WorkerFactory对象是通过NtCreateWorkerFactory创建的，我们得到的仅仅是代表这个对象的一个句柄——换句话说，我们并不能控制这个对象的具体内容， 但是我们构造写原语的确要伪造WorkerFactory对象的一些成员， 如何解决这个问题呢？

漏洞发现者提供了另外一个对象：EaFile。我们可以通过NtQueryEaFile达成向内存某一地址处写入我们想要数据的目的， 废话不说， 上反汇编代码：

这里需要强调一点， 由于WorkerFactory对象在第二次调用DeviceIoControl的时候会被释放掉， 因此上面18行处的ExAllocatePoolWithQuotaTag申请内存的调用， 只要传入合适的EaListLength值，就会再次得到被释放的这块内存。那么， EaListLength需要是多少合适呢？答案是WorkerFactory对象所占用的内存大小，所以我们需要知道WorkerFactory对象占多大内存：

可以看到WrokerFactory对象的大小为0xA0, 其分配的内存区域的POOL_TYPE为0， 即NonPagedPool。

继续进一步分析ExAllocatePoolWithQuotaTag函数调用：

发现EaListLength会被+4然后作为分配内存的长度， 因此我们如果想得到同一块内存， 在调用NtQueryEaFile的时候， EaListLength需要是0xA0 - 4, 下面是Exploit的对应代码(参考2)：

上面讲了这么多， 其实就是为了解决两个问题：

我们通过LoadLibrary和GetProcAddress得到了HalDispatchTable的地址， 然后利用NtQueryEaFile函数伪造一个WorkerFactory对象从而构造写原语， 利用构造的写原语覆盖了系统原本的HalQuerySystemInformation调用为我们Shellcode函数的地址。

到这里， 理论上我们只需要触发HalQuerySystemInformation调用即可执行我们的Shellcode了，如下(参考2)：

但是为了避免系统崩溃， 在Shellcode最后， 我们还需要将原来的HalQuerySystemInformation函数恢复回去。

那么，如何得到原HalQuerySystemInformation的函数地址呢？

通过上文的介绍， 我们依然利用WorkerFactory对象构造读语， 这次我们把目光转移到NtQueryInformationWorkerFactory上：

可以看到， 该函数中， 有一个解引用， 会将WorkerFactoryObject+0x64处的值+0xB4后， 再解引用， 赋值到返回内容的0x50位置处， 最终返回的内存大小为0x60。这里需要注意上面的v10是DWORD ， 所以(DWORD )v10 + 0x19等于(CHAR *)v10 + 0x64。

因此， 如果我们想要得到原来的HalQuerySystemInformation函数地址， 需要HalDispatchTable + 4 - 0xB4， 因此Exploit中的处理逻辑为(参考2)：

这样就得到了原本HalQuerySystemInformation的地址， 我们只需要在Shellcode最后恢复他即可。

对整个代码回顾， 关键脉络如下：

整个漏洞，最核心的技巧说白了其实是通过反复申请和释放同一块内存来完成的。

通过上文的分析我们可知，这块内存的大小即是WorkerFactory对象的大小， 但是有一个细节是最开始， 也就是afd!TransmitFile调用是如何申请一块WorkerFactory大小的内存呢？

让我们回到第一次DeviceIoControl调用的内存分配处：

所以所有关键参数都来自于我们的输入， 其中控制大小的参数会传递给IoAllocateMdl用于分配内存。让我们看一下IoAllocateMdl函数分配内存的细节：

可见作为长度传递给内存分配函数ExAllocatePoolWithTag的参数v8由VirtualAddress和Length计算而来， 而VirtualAddress和Length是受我们控制的。我们可以用以下代码暴力计算：

其结果如下：

最终得到的值和参考2中Exploit的Length其实是不相等的， 参考2中的Length计算后为0x20000, 经过实际测试， 使用我们计算得到的值0x1F224也可以成功提权。

实际上， 如果将上述代码最后的break去掉， 我们可以得到非常多可用的值， 0x20000就在其中。

以下利用代码来自于参考2, 仅对上面提到的Length做了修改， 且在Windows 7 x86 SP1上测试提权成功 :

其实这篇文章今年3月份的时候就已经开始写了， 期间因为手头的事情太多， 中间搁置了好长一段时间。后来发现近期又有好几篇这个漏洞的分析文章，于是就又捡起来写完， 算是凑个热闹。

写作过程中参考了很多前辈的文章， 也引用了部分前人的分析成果。本文涉及到的afd.idb、Exploit.c、Poc.c均已上传到Github参考3。

最后， 希望自己懒癌可以少犯病， 多做一些有意义的事情 ；）

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！