该漏洞源于 ws2ifsl.sys 驱动程序在处理内存对象时的缺陷，可能导致释放重引用错误。攻击者可以利用该错误，通过精心构造的输入，访问已释放的内存区域，从而执行恶意代码，提升权限。

本文测试环境：

进入驱动的主函数DriverEntry中可以看到，驱动程序首先创建了一个名为\\Device\\WS2IFSL的设备供用户态访问：

驱动程序中实现了多个与用户态交互的函数，如下图所示：

而MajorFunction的下标，实际上对应了Windows内核中的宏定义，对应的字段如下：

IRP_MJ_CREATE与IRP_MJ_CLOSE分别对应了我们在用户态创建文件与关闭文件句柄的请求，需要注意的是对于IRP_MJ_CLOSE来说，只有当我们传入的文件句柄对应的那个内核文件的引用计数为0时，才会真正执行。

由于DispatchCreate对应我们创建文件的函数，而文件句柄这是我们与驱动交互的入口，因此我将从这里开始分析，该函数的实现如图所示：

可以看到，函数会根据SystemBuffer + 0x8的值来判断我们要创建的是ProcessFile还是SocketFile，根据微软文档的结构体定义，其中SystemBuffer实际上对应的是一片用户缓冲区。

在此之后，会将FileObject, mode, SystemBuffer作为参数传递给要执行的函数，而对于参数FileObject来说，当我们用户态获得一个句柄时，内核就会创建对应的FileObject，该结构体可以在Windbg中查看到，结构如下：

其中DeviceObject对应的就是驱动创建的那个设备，也就是\\Device\\WS2IFSL，而FsContext则对应了驱动程序自定义的数据，接下来首先分析CreateProcessFile函数中，主要部分如下：

函数首先根据我们传入的Handle的值，通过ObReferenceObjectByHandle获取到句柄对应的对象，该函数的原型为：

而在此处，由于传入的ObjectType参数为PsThreadType，表示我们期望获取的对象为一个线程对象，当获取成功后会进行判断线程对象是否属于当前进程，如果是的话，则通过ExAllocatePoolWithQuotaTag函数分配一个大小为0x108的内存池，而其中第一个参数为POOL_TYPE，这是一个枚举类型，根据查阅微软的文档，可以知道实际上函数中的512对应的是NonPagedPoolNx，也就是非分页池，其中的Nx代表了权限位为不可执行。

当内存申请成功后，会进行一系列的赋值操作，并且进入InitializeRequestQueue，由于赋的值是用户不可控制的，因此对于大部分值我们不用太过关心，只需要关注在buffer + 0x0处存储了字符串corP，buffer + 0x8存储了当前进程的PID，并且在InitializeRequestQueue的如图所示的位置：

我们可以看到驱动程序将APC对象挂在了buffer->ApcObject的位置，该结构体实际上是我自己恢复的，对应的偏移实际上为buffer+0x30处，而第二个参数则是指明了要把APC挂在哪个线程上，这里的pthread_Object实际就是根据我们前面传入的句柄所获取到的，是用户可控的。

当赋值操作完成后，会将buffer挂在fileObject + 0x18的位置，根据前面给出的结构体定义，我们可以知道该偏移对应的是FsContext。

而对于CreateSocketFile函数，大致与CreateProcessFile的前置逻辑相同，函数如下：

可以看到区别主要存在于赋值不同与ObReferenceObjectByHandle的不同，先看ObReferenceObjectByHandle，根据前面我们给出的函数原型可以知道，此时的ObjectType变为了IoFileObjectType，这代表文件对象类型，如用户空间打开的 文件/设备句柄，那应该传入哪个文件或设备的句柄呢？

我们继续看下面的一段逻辑，首先将Object[0]给了v10，并通过IoGetRelatedDeviceObject来获取与Object[0]相关的是设备，其中DeviceObject这个全局变量对应的实际上就是驱动程序所注册的设备：\\Device\\WS2IFSL，然后取值判断，这里取得值有一点绕，我们拆开来看。

而根据条件判断的内容，驱动期望该指针偏移0处的内容为corP，期望该指针偏移8处的内容为PID，再根据前面CreateProcessFile函数对于赋值的处理，我们可以知道对于ProcessFile的fileObject，偏移0x18实际上对应了FsContext，而*(Fscontext)与*(Fscontext + 0x8)正好对应了字符串corP与进程的PID，因此我们可以知道，要传入的句柄实际上就是ProcessFile对应的句柄。

对于后面的赋值同样不用太过关注，只需要知道buffer + 0x0对于了字符串kcoS，而buffer + 0x10处存放了指向ProcessFile的fileObject的指针。

根据MajorFunction数组的下标的宏定义可以知道，该函数对于了两种请求，分别为IRP_MJ_READ与IRP_MJ_WRITE，也就是对应了读写请求，该函数如下：

从图中我们可以看出，实际上读写请求只对应了SocketFile，而进入函数DoSocketReadWrite之后，我们可以看到：

函数首先将fileObject + 0x18处的值取出，这个偏移不论是对于SocketFile还是ProcessFile来说都是FsContext，而接下来，函数将FsContext作为参数传入了GetSocketProcessReference，该函数如下：

先是与锁相关的操作，而后将FsContext->Processfile_ptr引用计数加1，然后返回了FsContext->Processfile_ptr，而根据前面的分析，我们可以知道这里FsContext->Processfile_ptr指向的是ProcessFile的fileObject，而需要注意的是，在这里引用计数+1的操作也只针对了ProcessFile的fileObject，而并未针对FsContext指向的缓冲区。

接下来在返回了fileObject后，将其作为参数传入了QueueRequest函数：

这里由于我结构体恢复的某些字段可能不太对，导致看着很奇怪，实际上我分析了一下，这里似乎是在将某个节点挂入链表的尾部。

而后执行了SignalRequest：

该函数最重要的一点就是调用了KeInsertQueueApc函数，将APC挂入了我们传入的线程对应的内核线程的APC列表中，并等待执行。

这里要注意的是，一旦APC被挂入了列表，那么即使我们关闭了句柄，也可以通过NtTestAlert等函数来强制执行。

该函数对应的请求是IRP_MJ_CLOSE请求，也就是对应的我们在用户态关闭句柄的操作，但此操作真正的执行时机是当我们传入的句柄的引用计数为0时，该函数如下：

我们可以看见，该函数会根据*(FsContext)的值来选择关闭哪个句柄，我们关注值为corP的情况，假设我们在用户态分别打开了ProcessFile与SocketFile，并用SocketFile进行读写，当我们关闭ProcessFile时，并不会触发DispatchClose，因为根据我们之前的分析，在SocketFile的读写操作中会增加ProcessFile的引用计数（在创建时也会增加引用计数），那么读写完毕后，引用计数减1，由于创建时也增加了引用计数，因此此时引用计数为1，而后我们关闭SocketFile，此时引用计数为0，因此ProcessFile与FsContext被释放，而此时APC已经被挂在了线程的APC队列中，造成了UAF。

至此，漏洞的成因已经基本分析完毕，我们总结一下，个人认为该漏洞的根本原因在于两点：

接下来就是分析该如何进行漏洞利用了。

首先我们思考一下我们可以控制哪些东西，如何进行交互。

对于该漏洞而言，我们可以控制ProcessFile对应的线程对象，也就是说可以控制将APC绑定到哪个线程对象上，而SocketFile实际则是依赖于我们创建的ProcessFile对象。

因此一个基本的交互思路是，我们创建一个ProcessFile与SocketFile，并获取到对应的句柄，但这里需要注意一个关键点，在驱动程序注册设备时，仅仅使用了以下代码：

对于IoCreateDevice来说，DeviceObject 是内核态的设备对象（DEVICE_OBJECT），存在于内核空间，内核里这个对象表示该驱动，但它 本身并没有用户态可访问的名字。因此正常的CreateFile是无法获得到句柄的，而根据bluefrostlab的文章，我们可以用NtCreateFile来获取句柄。

那么此时，我们需要思考如何组织我们要传入的数据（也就是线程的句柄）。

为了传入某个线程句柄，我们首先需要创建一个线程：

然后调用Windows的 CreateThread进行创建：

然后，我们需要创建一个ProcessFile，要传入的参数为hAPCThread1，并且由于我们期望其返回的是一个ProcessFile的句柄，因此定义如下函数：

根据NtCreateFile的函数定义：

我们首先使用如下方法生成一个ObjectAttributes：

而我们的数据都是存放在倒数第二个参数，也就是EaBuffer中的，而EA属性的结构体，在Windows的官方文档中同样能找到记载：

因此我们按照此定义，在我们的代码中定义一个相同的结构体，注意，由于我们是用户态，因此不能直接include对应头文件，所以需要自己定义：

而根据CreateProcessFile与DispatchCreate访问偏移，我们不难得出以下结构：

而观察_FILE_FULL_EA_INFORMATION，不难想到在+0x8的位置正好是name，因此我们可以写出以下代码：

最后，我们只需要使用：

即可创建出句柄。

对于SocketFile也是同理，根据偏移的关系，可以推测出：

因此可以仿造前面的CreateProcessFileHandle写出如下代码：

运行后，发现能成功触发断点：

接下来我们思考如何利用漏洞，根据前面的分析，要完成提权需要五步：

代码实现如下：

测试代码可以看见，当关闭句柄时，SocketHandle触发了DispatchClose操作：

我们观察一下当APC初始化完成后的内存布局：

当我们调用NtTestAlert时，实际上会触发到+0x20处的KernelRoutine，这是一个重要的偏移，我们可以思考劫持该函数指针。

根据Alex Ionescu的文章，我们可以使用Named Pipe去堆喷，从而获取到被我们释放的堆块，然后根据偏移伪造一个KAPC结构体，从而实现控制流劫持。

我们先触发一次NtTestAlert，观察此时寄存器的情况：

可以发现此时第一个参数，也就是rcx指向了我们buffer + 0x30的位置，此位置存放的是KAPC结构，而rdx则指向了0xffffffffffffffff，这里我不知道具体指向的是哪个，但只要是0xffffffffffff就行了，因此可以通过伪造结构来实现提权。

此时，我们可以通过Named Pipe进行堆喷，伪造一个布局，申请到释放的内存后，内存中应该如下：

基于上述布局，通过触发线程APC强制执行，就可以劫持控制流到SeSetAccessStateGenericMapping，最后成功提权：

最终EXP如下：

本人水平有限，如有错误，欢迎师傅们指正。

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！