Windows

一、前言 现今的Windows操作系统已经融合了虚拟化技术作为自身的核心功能，Windows平台下的虚拟化技术的应用也不仅限于Hyper-V虚拟化软件的应用，在一些用于保护Windows系统的安全功能中，虚拟化技术的使用也变得尤为重要。现在我们就来简单探索下Windows的VTL机制和IUM进程，这两种基于虚拟化技术的安全功能。 二、VTL机制和IUM进程介绍 Virtual Secure Mode(VSM)最早在Windows10和Windows Server 2016中被引入，是基于Windows平台下的虚拟化技术的安全功能，使用的是Hyper-V的虚拟化组件。 VSM的主要作用是，在这个安全功能开启的情况下，即使主机上的内核或者驱动程序（即Ring0层）受到攻击，受到VSM体系保护的数据依然可以保持安全，保证数据不被篡改或者无法被访问，甚至攻击者处于Ring0权限下。 与我们熟知的VMware或者QEMU虚拟化软件不同，Hyper-V的虚拟化实现是裸金属架构的，即Hypervisor层的组件运行在实体的硬件上，而无论是所谓的Guest(Child Parition)或者Host(Root Parition)都是Hypervisor层之上抽象出来的。 那么，Hyper-V的技术架构是VSM功能的基础，无论是Guest还是Host，实际上都可以通过Hypervisor来控制不同分区对硬件资源的使用能力从而实现在VSM中提及的安全功能。 VSM功能的引入同时引入了一个新的概念——VTL。 Virtual Trust Levels（VTL），VSM通过VTL来实现和维护隔离。VTL是有层级概念的，例如熟知的Ring0~3层级权限。但是与Ring0~3概念不同的是，VTL的层级权限是级别高的权限要高于级别低的权限。举个例子：VTL0的权限 < VTL1的权限；VTL1的权限 < VTL2的权限。在微软对VTL的代码实现里，最多支持16个级别VTL，但是截止到目前的关于VTL的代码中，微软只实现了2个级别的VTL。 为了更直观的展示VTL的作用，这里使用了微软官方给出的IUM架构体系图。 从图中可以看到，我们所熟知的Windows内核态和用户态都属于VTL0级别下，而SecureKernel和运行在同VTL层级下的用户态进程属于VTL1级别下。此时，假如我们在VTL0种进行内核调试，都无法修改VTL1层级下的用户态进程空间内存。这个例子说明了低级别VTL无法影响到高级别VTL内存空间，不同的VTL级别之间有着明显的隔离边界。 有了VTL这个概念之后，下面我们来介绍下什么是Isolated User Mode(IUM)进程。通俗来讲，IUM进程就是运行在VTL1层级下的用户态进程。最简单的例子就是LSAIso.exe进程，当这个进程运行在VTL1层级下时，无论是在用户态还是内核态都无法修改这个进程的内存空间，同样地，对其进行调试也是无法进行的。 下面，我们一起来探索VTL机制和IUM进程（以及如何调试IUM进程）的一些内部细节。 三、必要的硬件虚拟化知识（Intel） 在探索之前，我们还需要简单的了解下CPU硬件虚拟化知识，这里我们以Intel处理器(Intel VT-x)加以介绍。 这里首先要介绍的是Intel VT-x和VMX是什么。Intel VT-x的全称是Intel Virtualization Technology for x86，这个东西就是所谓的Intel硬件虚拟化技术，而VMX是其实现的架构，全称为Virtual-Machine Extensions。在VMX下引入了两个概念：VMX root operation和VMX non-root operation模式。 VMX的root和non-root operation模式可以简单地理解成，hypervisor也就是虚拟化层，即VM管理者(VMM, virtual machine monitor)和Guest所使用的环境。这两种模式可以互相转换，当从VMX的root模式转换到non-root模式时，这个行为被称作VM-entry。那么当VMX的non-root模式切换到root模式，这个行为被称作VM-Exit。 假设目前VMX处于non-root状态，此时是在执行Guest中的代码，如果执行时遇到了比如CPUID，读写MSR寄存器等操作时，Guest操作系统会被暂停，并产生Vm-Exit事件，同时陷落入VMM，即root operation状态中。VMM根据不同的VM-Exit原因来处理（模拟）此时Guest的执行指令，处理数据并返回结果，最后vmm通过执行vmresume指令重新让Guest系统继续运行，此时的VMX状态又变回了non-root状态。 在VMX进行root和non-root operation状态切换时，VMCS（Virtual Machine Control Structure）用来配置此时发生切换的处理器状态和执行的环境。在Hyper-V的虚拟化环境中，每个虚拟处理器都对应着一个或者多个VMCS。 VMCS中有很多字段，对应着当前虚拟处理器的状态信息，比如用于记录当前VM-Exit信息的"Exit reason"字段，通过阅读Intel手册发现这个字段对应的ID是0x4402。因为VMCS中的字段信息无法直接通过读取物理内存的方式读取到，所以这里必须使用Intel给出的指令集vmread/vmwrite来读写对应的字段内容。 #define EXIT_REASON_EXCEPTION_NMI 0 #define EXIT_REASON_EXTERNAL_INTERRUPT 1 #define EXIT_REASON_TRIPLE_FAULT 2 #define EXIT_REASON_INIT_SIGNAL 3 #define EXIT_REASON_SIPI_SIGNAL 4 #define EXIT_REASON_INTERRUPT_WINDOW 7 #define EXIT_REASON_NMI_WINDOW 8 #define EXIT_REASON_TASK_SWITCH 9 #define EXIT_REASON_CPUID 10 #define EXIT_REASON_HLT 12 #define EXIT_REASON_INVD 13 #define EXIT_REASON_INVLPG 14 #define EXIT_REASON_RDPMC 15 #define EXIT_REASON_RDTSC 16 #define EXIT_REASON_VMCALL 18 #define EXIT_REASON_VMCLEAR 19 #define EXIT_REASON_VMLAUNCH 20 #define EXIT_REASON_VMPTRLD 21 #define EXIT_REASON_VMPTRST 22 #define EXIT_REASON_VMREAD 23 #define EXIT_REASON_VMRESUME 24 #define EXIT_REASON_VMWRITE 25 #define EXIT_REASON_VMOFF 26 #define EXIT_REASON_VMON 27 #define EXIT_REASON_CR_ACCESS 28 #define EXIT_REASON_DR_ACCESS 29 #define EXIT_REASON_IO_INSTRUCTION 30 #define EXIT_REASON_MSR_READ 31 #define EXIT_REASON_MSR_WRITE 32 #define EXIT_REASON_INVALID_STATE 33 #define EXIT_REASON_MSR_LOAD_FAIL 34 #define EXIT_REASON_MWAIT_INSTRUCTION 36 #define EXIT_REASON_MONITOR_TRAP_FLAG 37 #define EXIT_REASON_MONITOR_INSTRUCTION 39 #define EXIT_REASON_PAUSE_INSTRUCTION 40 #define EXIT_REASON_MCE_DURING_VMENTRY 41 #define EXIT_REASON_TPR_BELOW_THRESHOLD 43 #define EXIT_REASON_APIC_ACCESS 44 #define EXIT_REASON_EOI_INDUCED 45 #define EXIT_REASON_GDTR_IDTR 46 #define EXIT_REASON_LDTR_TR 47 #define EXIT_REASON_EPT_VIOLATION 48 #define EXIT_REASON_EPT_MISCONFIG 49 #define EXIT_REASON_INVEPT 50 #define EXIT_REASON_RDTSCP 51 #define EXIT_REASON_PREEMPTION_TIMER 52 #define EXIT_REASON_INVVPID 53 #define EXIT_REASON_WBINVD 54 #define EXIT_REASON_XSETBV 55 #define EXIT_REASON_APIC_WRITE 56 #define EXIT_REASON_RDRAND 57 #define EXIT_REASON_INVPCID 58 #define EXIT_REASON_VMFUNC 59 #define EXIT_REASON_ENCLS 60 #define EXIT_REASON_RDSEED 61 #define EXIT_REASON_PML_FULL 62 #define EXIT_REASON_XSAVES 63 #define EXIT_REASON_XRSTORS 64 #define EXIT_REASON_UMWAIT 67 #define EXIT_REASON_TPAUSE 68 #define EXIT_REASON_BUS_LOCK 74 #define EXIT_REASON_NOTIFY 75 通过vmread读取0x4402 id字段的内容，就可以得到VM-Exit的原因，VMM根据上图中这些若干的原因进行处理，完成处理后，将结果改写到例如Guest中的寄存器中，此时也需要通过vmwrite改写其中关于Guest寄存器信息的字段，最后通过vmresume将控制权交还Guest。...

一、前言 CVE-2024-26229是今年4月微软修补的一个任意地址写零漏洞，该漏洞位于csc.sys驱动中。攻击者在Windows上获得较低权限的任意代码执行后，可以利用该漏洞将低权限提升至system权限。目前Exp由varwara公布在了github上。 二、csc.sys简介 csc.sys(Windows Client Side Caching Driver)是脱机文件(offline files)功能的一部分。脱机文件功能是默认在本机存一份共享文件的副本，这样做的优点有两点，一方面可以节省网络流量，另一方面是断网条件下，仍然可以使用共享文件夹，等到有网之后再进行同步。默认副本文件存储在C:\Windows\CSC文件夹中，普通用户没有权限访问该文件夹的内容。 下面以SMB协议为例，演示如何开启脱机文件功能。 首先准备两台虚拟机，一台为SMB server，一台为SMB client。 在SMB Server首先新建一个文件夹，然后共享此文件夹，并设置此权限为完全控制。 在SMB client打开控制面板进入同步中心->管理脱机文件->启动脱机文件。 然后访问SMB server，点击始终脱机可用。 之后就会出现一个新的文件夹，即为本机副本。 此时关闭share文件夹分享，仍然能操作share文件夹。 三、漏洞成因分析 通过README可以看出该漏洞产生的原因是在csc.sys中没有校验用户态以METHOD_NEITHER方式和驱动进行通信时用户态传入的缓冲区地址是否是合法地址，从而导致任意地址读或者任意地址写。 下面介绍一下windows用户态与驱动的通信方式来解释为什么以METHOD_NEITHER与驱动进行通信时需要对用户态传入的地址进行合法校验。 在windows中用户态与驱动的通信方式共有三种: METHOD_BUFFERED METHOD_IN_DIRECT METHOD_OUT_DIRECT METHOD_NEITHER METHOD_BUFFERED方式对UserInputBuffer和UserOutputBuffer都进行缓冲，驱动程序无需对用户态传入的缓冲区地址进行校验。 METHOD_IN_DIRECT和METHOD_OUT_DIRECT只对UserInputBuffer进行缓冲，对于UserOutputBuffer采用的是将用户态地址锁定(即不让其换出内存)，然后映射为内核地址。在驱动写入后，重新映射为用户态地址。 METHOD_NEITHER (也就是出现漏洞的这种通信方式) 驱动程序直接读写用户态的缓冲区，优点是读写更快，缺点是驱动程序在读写缓冲区之前需要使用ProbeForRead/ProbeForWrite函数去探测地址是否合法。就可能会出现漏洞，例如用户态的传入的UserInputBuffer和UserOutputBuffer均为内核态地址，驱动就会根据用户态传入地址读写，即可造成任意地址读写。 四、补丁分析 可以看到有两个函数有改动，既然本漏洞是关于I/O control的，那么优先看CscDevFcbXXXControlFile这个函数改动。 通过bindiff可以看到从00000001C006B243这个块开始有所不同，定位到对应的反编译的伪c代码进行比较。 在patch之后的代码加了一个if判断 如果if 判断条件为true，则首先在使用前判断v12是否小于0x24 如果小于0x24，则调用失败 如果大于等于0x24，则会判断(a1+40)+64的是否不为0，这里推测如果为1的话，应该表示该请求来自用户态 如果不为0，则会使用ProbeForWrite探测a1+536的地址是否合法 然后对a1+536的位置写入一个8字节的0 (这里可能就是未patch的漏洞点了) 如果if判断条件为false，则使用原来的漏洞代码 patch代码保留原来漏洞代码目的推测为微软可能认为新代码可能会影响正常的功能，一旦遇到问题可以只需要改一下某个标志位就可以回滚回原来的代码，等到新代码完全稳定后估计就会删除原来的漏洞代码。 五、漏洞触发流程分析 从目前的分析来看，这个漏洞模式比较简单，为什么之前没有被人扫描到或者分析出来，我认为有两点原因。 ida反编译显示错误，有的时候你看csc.sys驱动的DriverEntry函数,可能如下图所示： 如果你多次Undefine然后重新反编译DriverEntry，就会发现DriverEntry函数是很长的。 csc.sys是一个内核网络微型重定向器驱动程序(Kernel Network Mini-Redirector Driver)使用了重定向驱动器缓冲子系统 (Redirected Drive Buffering Subsystem) 使得处理DeviceIoControl调用栈过深，不易被发现。 由DriverEntry可以看到用户态所有请求都由CscFsdDispatch处理，跟进CscFsdDispatch函数可以发现大部分的请求都是由导入函数RxFsdDispatch处理 RxFsdDispatch是由rdbss.sys中实现，下面介绍以下csc.sys与rdbss.sys交互为例介绍rdbss机制。 5.1 rdbss机制分析 csc.sys与rdbss.sys的交互分为三个状态，并且是顺序的。 5.1.1 csc.sys在初始化时调用RxRegisterMinirdr()初始化PRDBSS_DEVICE_OBJECT的部分成员 RxRegisterMinirdr函数声明如下： NTSTATUS RxRegisterMinirdr( [out] OUT PRDBSS_DEVICE_OBJECT *DeviceObject, [in, out] IN OUT PDRIVER_OBJECT DriverObject, [in] IN PMINIRDR_DISPATCH MrdrDispatch, [in] IN ULONG Controls, [in] IN PUNICODE_STRING DeviceName, [in] IN ULONG DeviceExtensionSize, [in] IN DEVICE_TYPE DeviceType, [in] IN ULONG DeviceCharacteristics ); 这里主要关注MrdrDispatch这个参数，这个参数指向网络微型重定向驱动的调度表的指针。此调度表包括网络微型重定向驱动的配置信息和指向由网络微型重定向器内核驱动程序实现的回调例程的指针表。RDBSS 通过此回调例程列表调用网络微型重定向器驱动程序。...

一、前言 本文主要介绍了使用调试器对Windows操作系统的内核层和hypervisor层进行双机调试的几种常见和不常见的方法。本文中使用的windbg调试器和其附带的实用调试工具都可以在windows sdk安装包中选择安装，windows sdk安装包官方的下载地址是: (https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/)。 有需要的读者可以自行下载并安装。 二、串口调试 首先我们先来介绍使用VMware虚拟机的情况下如何使用串口进行双机调试Windows内核及hypervisor。 在VMware的虚拟机设置中，添加"串行端口"设备后，并设置"串行端口"设备"使用命名的管道"，这里命名管道的名称可以自己设定，并分别选择"该端是服务器"和"另一端是应用程序"。如下图。 然后我们在被调试机中设置bcdedit参数，这里的目的是在系统启动过程中添加debug参数。如下图。 在被调试机中我们分别使用bcdedit /dbgsettings serial debugport:1 baudrate:115200和 bcdedit /hypervisorsettings serial debugport:1 baudrate:115200命令将Windows内核和hypervisor的调试参数设置为串口调试，串口为com1，波特率为115200。然后再使用bcdedit /debug on和bcdedit /set hypervisordebug on命令分别开启windows内核和hypervisor层的调试。最后设置dbgtransport为kdcom.dll，这里是为了保证被调试机在系统启动过程中使用串口进行调试。 现在被调试机已经整装待发做好了被调试的准备，但调试机还需要一些配置。因为我们需要同时调试windows的内核和hypervisor，而且在被调试机的参数中使用了同一个串口(com1)作为调试串口，所以需要将不同层级的调试数据分发，根据不同层级将调试数据分发到不同的命名管道。我们可以使用& 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\vmdemux.exe' -src pipe:pipename=com2命令实现这一过程。 成功运行如上命令后，vmdemux进程会自动生成两个命名管道\\.\pipe\Vm0和\\.\pipe\Vm1。分别使用& 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe' -k com:port=\\.\pipe\Vm0,pipe,resets=0,reconnect和& 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe' -k com:port=\\.\pipe\Vm1,pipe,resets=0,reconnect命令打开windows hypervisor和内核的调试窗口。如下图。 下面我们介绍在双实体机的情况下如何使用串口进行双机调试。 双实体机进行串口调试需要被调试机的主板上保留9针串口，在10年前的电脑主板上，串口几乎是标准配置，然而随着主板厂商的革新，主板串口也渐渐退出历史舞台。 除了需要主板中保留串口外，还需要拥有一条串口调试线：Null-modem线，或者准备一条2，3交叉线。关于Null-modem调试线的线序如下图，感兴趣的读者可以自己手动做一条。 当使用串口调试线连接好调试端和被调试端，就可以使用 & 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\vmdemux.exe' -src com:port=com2命令将不同层级的数据分发到指定的层级，实现windows内核和hypervisor调试。 三、网络调试 Windows内核和hypervisor调试中，可以使用网络进行调试，不需要特殊的调试线连接两台机器，网络调试大大方便了双机调试中的准备过程。 首先，配置被调试机bcdedit配置，这里假设我们的调试机IP地址为192.168.111.1，调试hypervisor的端口为52201，调试windows内核的端口是52202。运行如下图的命令，设置网络调试，最后将dbgtransport设置为kdnet.dll。 在图中可以看到，如果成功设置了网络调试后，会返回一个key，这个key是用来给调试机中的windbg连接被调试机使用的。这里这两个key要先记下来。 重启被调试机后，在调试机端使用& "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe" -k net:port=52202,key=rq644uvs2p16.3ked98d1isrrq.hr7oioflkdt2.37b29ko4f79yj和& "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg....

一、研究背景 （一）操作系统内核漏洞 操作系统是计算机系统的核心软件，其主要功能在于管理计算机系统中的各种软硬件资源，并为计算机用户和用户程序提供访问这些资源的统一抽象。为达到这一设计目标，操作系统内核通常运行在称为内核态的高特权级执行环境中。一旦操作系统内核被恶意攻击者非法侵入，攻击者便可立即拥有对整个计算机系统的控制权，造成极大危害。因此，针对操作系统内核的漏洞挖掘一直是学术界和工业界的研究重点。 Windows操作系统是桌面计算机领域最广泛应用的操作系统之一，在网络空间中扮演着至关重要的角色。与之对应的，Windows操作系统中存在的安全漏洞也往往具有广泛的影响和严重的潜在危害。攻击者可以利用这些漏洞来进行大规模的网络攻击，给网络安全带来严重的威胁。例如，在2017年流行的WannaCry勒索病毒攻击，就是利用了MS17-010“永恒之蓝”漏洞，其受害者遍布全球多国，造成了巨大的损失。 在Linux操作系统上，以Syzkaller为代表的模糊测试工具可以7x24小时不间断地对内核进行漏洞挖掘，并自动化地生成漏洞报告供维护者查阅。然而，在Windows操作系统上，还没有出现影响力和测试效果能够比拟Syzkaller的开源工具。造成这一差异的原因是多方面的，例如，研究人员可以通过对Linux源码进行静态分析得到供Syzkaller使用的Syzlang模版，其中包含对系统调用接口的完整描述，由此可以驱动模糊测试。但在Windows上，由于内核是闭源的，对其系统调用接口的分析过程更为复杂和困难。 通过分析近年来披露的Windows内核态漏洞，我们发现，这些漏洞大多是由独立的研究人员或安全研究团队发现，并且极大地依赖于专家知识，只在特定的情况下使用了模糊测试等自动化方法来辅助漏洞挖掘。奇安信天工实验室近年来在Hyper-V中发现的漏洞，也同样离不开安全研究员对Hyper-V整体架构和漏洞模式的深入理解。 有鉴于此，笔者也针对近年来披露的Windows内核态漏洞进行了人工的分析和研究，并主要聚焦于竞态条件这一漏洞类型。本文便是对相关研究发现的总结。 （二）竞态条件漏洞 竞态条件是计算机科学中的一个重要概念，它指的是在多线程或多进程环境中，由于不恰当的同步操作或竞争资源的访问而导致的不确定性行为。在现代操作系统中，多线程的程序调度是至关重要的一项任务，它直接影响了计算机系统的性能和资源利用效率。多线程编程允许程序同时执行多个任务，从而提高了系统的响应速度和并发处理能力。然而，为了有效地管理这些线程，操作系统必须具备高效的调度机制，决定哪个线程获得CPU时间片，以确保各个线程能够合理地分享计算资源。这一调度决策是基于一系列算法和策略进行的，涉及到线程的优先级、状态管理、抢占机制以及资源争用解决等多个方面。 这一调度机制也导致多个线程或进程在争夺资源的同时，执行顺序并不确定，因此可能会产生意想不到的结果。为了避免问题，多线程场景下对关键资源的访问需要利用加锁、同步等机制来保证安全。倘若多个线程同时访问共享变量或资源，而没有适当的同步机制来保护这些资源，这可能导致数据损坏、程序崩溃或不一致的结果，从而带来严重的安全和可靠性问题。 图1：典型的竞态条件成因，两个线程无保护地访问同一个内核对象 如图1所示，漏洞CVE-2022-29142的原因正是两个线程可以同时访问同一个内核对象，如果其中一个线程试图关闭该对象的句柄，另一个线程便可能访问已被释放的指针。 本文将会具体介绍竞态条件漏洞带来的潜在风险，并描述复现真实存在于Windows内核中的竞态条件漏洞时的发现。 二、漏洞分析采用的关键技术 在进行针对Windows内核的漏洞分析和研究时，主要采用的关键技术包括：补丁对比分析、二进制逆向分析、竞态条件构建和调试等。 （一）补丁对比及二进制逆向分析 通过在CVE数据库中的检索，发现近年来披露的Windows内核漏洞中不乏用户提权和任意代码执行等高危漏洞。然而，由于微软积极控制漏洞的影响，相关漏洞的公开PoC程序数量相对较少。对于那些没有公开PoC的漏洞，往往只能获得漏洞发现者通过博客或社交媒体透露的少量信息，难以由此开展系统性的漏洞研究。考虑到这些漏洞的修复补丁存在于Windows安全更新中，通过对补丁进行分析，包括进行补丁的解包和二进制对比等，能够有效地从中提取出更新内容，识别受影响的模块，并可以进一步地从中提取关键的补丁点，由此分析补丁所修复的漏洞。 为了能够解析微软的Windows安全补丁，首先需要了解补丁的格式以及获取方法。打包补丁的文件格式包括：.MSU（Microsoft Standalone Update）和.CAB（Cabinet）格式。补丁一般会作为 Windows 更新的一部分自动分发到用户设备上，但也可以直接从微软的更新目录中下载独立的补丁。此前，微软主要提供顺序的更新包，它们必须依次安装到用户的系统中。如今，更新以累积的方式提供，这意味着基本系统版本中的所有必需更新都包含在补丁包中，这也允许用户平滑地升级系统版本。此外，出于节省带宽等考虑，许多更新以增量的方式分发，即：更新包中只包含对特定二进制目标的修补方式，而不包含全部的文件。这也进一步增加了补丁分析的难度。 对于每次安全更新，具体的补丁文件可以从Microsoft Update Catalog上获取。.MSU格式的补丁在使用expand.exe程序解包后，将能够获得.CAB格式的补丁文件，且这些文件按照指令集和二进制差异类型进行命名。对于补丁内容的进一步提取，将依赖于微软提供的msdelta.dll库。该库中提供了ApplyDelta系列函数用于执行Windows系统更新。通过C或Python语言调用相关库函数，即可实现打补丁的过程，获得补丁之后的二进制文件。 图2：漏洞CVE-2023-21537补丁对比 最后，通过BinDiff或Diaphora等二进制对比工具，即可完成对补丁内容的分析，并由此定位到漏洞点。如图2所示，以漏洞CVE-2023-21537为例，通过对比分析补丁前后的函数控制流图，可以发现补丁新增了参数检查的分支（见红色框）。在确定可能的漏洞点后，即可开展人工的逆向分析。 （二）Windows内核调试 在成功确定漏洞点后，下一步是构造PoC程序，并触发漏洞行为，例如使内核出现崩溃，造成蓝屏死机（Blue Screen of Death）。再此基础上，可以进一步构造漏洞利用的方式，例如，利用释放后使用（Use after free）漏洞来覆盖关键的内核数据结构，实现进程提权的效果。 为了触发内核中的漏洞代码的执行，需要构造用户态程序执行系统调用或驱动程序的IoControl调用。这些函数调用往往需要大量的参数，并且，参数需要满足一定的约束条件。在实际的测试中，发现通过人工构造的参数难以一次性通过检查，必须不断进行调试并修改PoC程序。 微软提供了WinDbg程序用于支持Windows内核调试，但由于在内核函数中触发断点等操作会中断整个系统的执行，因而必须在另一台计算机上运行WinDbg，并通过TCP连接至待调试的计算机。在实际的实验中，相关的内核调试借助Hyper-V虚拟机完成。经笔者测试，运行在Hyper-V虚拟机中的Windows系统开启内核调试模式并设置端口和密钥参数后，即可在Host上通过WinDbg程序开启TCP连接进行内核调试。 三、典型漏洞分析 笔者总共分析和研究了10个近年来被披露并分配了CVE编号的Windows内核竞态条件安全漏洞，具体的漏洞编号、内核模块和漏洞类型情况如表1所示。下面将通过案例分析介绍其中的典型漏洞，以及对未来针对此类漏洞进行自动化挖掘的启发。 CVE ID 内核模块 漏洞类型 CVE-2018-7249 secdrv.sys UAF CVE-2018-8410 ntoskrnl Double dereference CVE-2018-8611 ntoskrnl UAF CVE-2020-1015 UMPS UAF CVE-2021-26868 win32k UAF CVE-2021-40449 win32k UAF CVE-2021-41335 ntoskrnl OOB CVE-2022-29142 ntoskrnl UAF CVE-2023-21536 ETW UAF CVE-2023-21537 mqac....