CVE-2026-42980 公开漏洞利用 + 研究
Ots安全
2026年7月19日 19:39
广东
在小说阅读器读本章
去阅读
威胁简报
恶意软件
漏洞攻击
该存储库包含CVE-2026-42980的公开披露材料，这是一个 Windows 内核 WMI 整数下溢漏洞，可被利用以NT AUTHORITY\SYSTEM在易受攻击的实验室构建中实现本地权限提升。
存在漏洞的站点位于 WMI 序列化路径内部ntoskrnl.exe：
这两个站点都维护着一个 32 位剩余输出计数器。存在漏洞的构建版本会减去一个由提供程序报告的已对齐大小，但并未证明该大小小于或等于剩余计数器。如果该大小大于剩余计数器，则无符号计数器会回绕到一个较大的值。接下来的 WMI 序列化步骤会将缓冲区视为仍有充足空间，并写入超出已分配内核末尾的内容SystemBuffer。
该漏洞利用使用了0x228130路径 ( nt!WmipQuerySingleMultiple)，因为它提供了一个实用的内置触发器：初始容量门基于调用者控制的 WNODE 项目大小估计，而后续的减法则使用提供程序返回的实际序列化 WNODE 大小。
补丁差异：确切的易受攻击函数
将存在漏洞的内核与已修补的内核进行比较，结果显示微软以相同的方式更改了两个 WMI 路径：未经检查的减法被替换为受保护的饱和减法Feature\_1045423416。
nt!WmipQueryAllDataMultiple（IOCTL 0x22812C）
查询路径会序列化多个 WMI 数据块，并保持剩余输出长度。在存在漏洞的版本中，循环执行以下逻辑：
AlignedSize = (QueryInfo[0] + 7) & 0xFFFFFFF8;
CurrentOutputBuffer = (char *)CurrentOutputBuffer + AlignedSize;
TotalSize += AlignedSize;
OutputBufferLength -= AlignedSize; // vulnerable: unchecked unsigned subtract
在指令层面，存在漏洞的操作是：
nt!WmipQueryAllDataMultiple+0x29a:
sub r14d, eax ; r14d = remaining, eax = aligned provider size
打完补丁后的版本将其改为饱和形式：
v = OutputBufferLength - AlignedSize;
if (Feature_1045423416__private_IsEnabledDeviceUsageNoInline())
v = -(unsignedint)(AlignedSize < OutputBufferLength) & v;
OutputBufferLength = v;
0xFFFFFFFF仅当减法运算不会导致下溢时才需要 掩码。如果AlignedSize >= OutputBufferLength出现下溢，则掩码变为零，剩余计数器将被限制在一个值，0而不是溢出。
nt!WmipQuerySingleMultiple（IOCTL 0x228130）
漏洞利用路径是其背后的单实例/多项目路径：
\\Device\\WMIDataDevice
IOCTL_WMI_QUERY_SINGLE_MULTIPLE = 0x00228130
存在漏洞的版本包含相同的算术错误：
AlignedActualSize = (ReturnedDataSize + 7) & 0xFFFFFFF8;
TotalRequiredSize += AlignedActualSize;
OutBufferSize -= AlignedActualSize; // vulnerable: unchecked unsigned subtract
差异分析结果显示，存在漏洞的站点是：
nt!WmipQuerySingleMultiple+0x401
指令级操作等同于：
sub dword ptr [rsp+4Ch], eax ; outRemaining -= alignedActualSize
打过补丁的版本应用了相同的饱和模式：
t = OutBufferSize - AlignedActualSize;
if (Feature_1045423416__private_IsEnabledDeviceUsageNoInline())
t = -(unsignedint)(AlignedActualSize < OutBufferSize) & t;
OutBufferSize = t;
这证实了这两个易受攻击的函数都属于同一算术错误类别：从剩余输出计数器中未经检查地减去由提供程序控制的对齐大小。
用户模式下的可达性
通过 WMI 数据设备，可以从正常的本地进程访问这些易受攻击的路径：
[user mode]
NtDeviceIoControlFile(\\Device\\WMIDataDevice, ioctl, ...)
-> nt!WmipIoControl
IOCTL0x22812C-> nt!WmipQueryAllDataMultiple
IOCTL0x228130-> nt!WmipQuerySingleMultiple
-> nt!WmipQueryAllData / providerexecution
-> nt!WmipForwardWmiIrp
-> WMIprovider
最后，我使用以下方法进行漏洞利用IOCTL 0x228130，因为请求格式允许我准备两个 WNODE 输入：
1.项目 0：造成会计欠溢；
2.项目 1：利用攻击者控制的字节实现越界写入。
PoC\Device\WMIDataDevice直接打开，并且使用WmiOpenBlock/ WmiQueryAllDataWfromadvapi32.dll来发现具有可用触发窗口的实时 WMI 实例。
触发器中的精确算术
可利用的条件WmipQuerySingleMultiple是门估计值与后来减去的值不匹配。
对于每个 WNODE 项，门使用如下形式的所需尺寸估算值：
requiredSize = (DataSize + 73) & ~7;
对于 WMI 实例名称，其大小估算实际上与调用方的数据项大小/名称长度相关。但是，在提供程序路径运行后，调用方会减去实际序列化的 WNODE 大小：
alignedActualSize = (ReturnedDataSize + 7) & ~7;
outRemaining -= alignedActualSize;
可被利用的关系是：
requiredSize <= outRemaining
alignedActualSize > outRemaining
这意味着 WNODE 项通过了初始容量检查，但后续的减法运算出现了溢出。
验证过程中观察到的一个具体窗口是：
nameLen = 0x4c
requiredSize = (0x4c + 0x49) & ~7 = 0x90
R = 0x94
aligned = 0x98
slop = 4
gate: 0x90 <= 0x94 -> accepted
subtract: 0x94 - 0x98 -> 0xFFFFFFFC
在另一个实验室构建/配置文件中，选择了动态解析器：
guid#156 = {2e2d2463-b537-4da7-8eee-51306f1f482f}
class = WmiMonitorConnectionParams
nameLen = 0x56
requiredSize = 0x98
R = 0x9c
aligned = 0xa0
slop = 4
overwriteOff = 0xf1e
确切的 GUID 并非根本原因。关键在于测量的时间窗口： ALIGN8(R) > R即闸门仍然能够接收物品的时间段。
GUID 为何会改变
该概念验证方案不依赖于单一的WMI提供程序。它自带WMI GUID数据集，并在运行时动态扫描可用的窗口。所选的提供程序取决于Windows版本、虚拟机配置文件、已启用设备、监视器配置、网络状态以及其他WMI公开的硬件状态。
实验室运行中发现的成功或候选供应商示例包括：
这就是为什么该漏洞利用程序会动态计算覆盖几何形状的原因。如果窗口从 变为R=0x94/aligned=0x98，R=0x9c/aligned=0xa0覆盖偏移量也必须随之改变。
PoC 使用的核心公式是：
phase = (alignedActualSize + WMI_WNODE_INSTANCE_DATA_OFFSET) & (0x1000 - 1);
overwriteOffset = phase ? (0x1000 - phase) : 0;
和：
WMI_WNODE_INSTANCE_DATA_OFFSET = 0x42
WMI_POOL_CHUNK_STRIDE = 0x1000
对于0x9c/0xa0备用窗口，这将产生overwriteOff=0xf1e。
将包装变成越界写入
在处理完第 0 项后outRemaining，内核会处理第 1 项，此时内核认为输出缓冲区仍有大量剩余容量。因此，第 1 项的 WNODE 会被序列化到内核执行完毕之后SystemBuffer。
有用的部分是 WNODE 实例数据的复制。在漏洞利用过程中，攻击者控制着以下位置复制的字节：
OOB WNODE + 0x42
这就是代码定义的原因：
#define WMI_WNODE_INSTANCE_DATA_OFFSET 0x42
第二个 WNODE 数据缓冲区经过特殊处理，使得此实例数据副本落在相邻命名管道数据队列条目的头部。
资源池布局与存储桶匹配
目标对象是 npfs 命名管道数据队列条目（NP\_DATA\_QUEUE\_ENTRY标记为NpFr已使用）。该漏洞利用程序会创建多个管道并填充它们，从而使内核分配一系列大小相同的管道数据对象。
一个重要的细节是，WMI 请求使用METHOD\_BUFFERED内核分配 IOCTL SystemBuffer：
max(InputBufferLength, OutputBufferLength)
如果 WMISystemBuffer分配和喷洒管道数据队列条目不在同一个池桶中，则 OOB 写入将无法可靠地到达目标对象。因此，该漏洞利用程序会填充 WMI 输入长度：
WMI_SYSBUF_INLEN = 0xff0
并使用管道写入来生成有效0x1000大小为 1 的池对象。重要的几何形状是：
pipe data body = 0xff0
data queue header = 0x30
effective pool stride = 0x1000
在较小的桶校准案例中，同样的原理体现在以下方面：
Sprayed NpFr DQE = 0x30 + 0xb0 = 0xe0 -> 0xf0 chunk
SystemBuffer before = max(0x38, 0x94) -> 0xb0 chunk (wrong bucket)
SystemBuffer after = max(0xe0, 0x94) -> 0xf0 chunk (matching bucket)
公开漏洞利用了较大的0xff0/0x1000几何形状作为最终链。
损坏管道队列条目
第一次 WMI 触发会破坏目标管道条目并增加其可读大小。后续PeekNamedPipe调用可能会过度读取原始管道数据，并泄露相邻内核池的元数据。
该漏洞利用程序使用了一个稳定的泄漏偏移量：
NPFS_LEGACY_LINKS_LEAK_OFFSET = 0xfd0
在该偏移量处，它提取队列/列表元数据，以保持管道结构的一致性，同时构建更强大的原语。
在数据泄露阶段之后，该漏洞利用程序会再次触发 WMI，并使用不同的有效载荷将损坏的队列条目重塑为 IRP 支持的队列条目。这使得 PeekNamedPipe攻击者可以从其选择的内核地址复制数据，从而获得任意内核读取权限。
从任意读取到令牌替换
通过任意内核读取，该漏洞利用程序可以定位当前进程和 SYSTEM 进程。偏移量由 Windows 版本号决定。高级路径如下：
IRP
-> ETHREAD via _IRP.Tail.Overlay.Thread
-> current EPROCESS via KTHREAD/ApcState.Process
-> ActiveProcessLinks walk
-> PID 4 EPROCESS
-> SYSTEM token
然后，利用 IRP 完成/写入路径将 SYSTEM 令牌值写入当前进程EPROCESS.Token字段。之后，漏洞利用程序修复损坏的管道条目并启动：
cmd.exe /k whoami
生成的流程如下：
nt authority\\system
公开 PoC 中的漏洞利用阶段
公开的PoC将链条分阶段打印出来：
- 检测 Windows 版本并选择内核结构偏移量；
- 解决NtFsControlFile，，WmiOpenBlock和WmiQueryAllDataW；
- 分配 WMI 缓冲区；
- 喷洒命名管道；
- 向管道内注水，形成所需的泳池对象；
- 释放一个管道物体以形成一个孔；
- 打开\Device\WMIDataDevice;
- 解析 WMI 触发窗口并发送IOCTL 0x228130；
- 找到损坏的管道；
- 泄露NPFS元数据；
- 构建任意读取；
- 找到进程 ID 4 并读取系统令牌；
- 将 SYSTEM 令牌写入当前进程；
- 修复管道物体；
- 启动 SYSTEM shell。
补丁影响
该补丁在算术层阻止了原语攻击。一旦剩余计数器饱和为零而不是溢出，下一个 WNODE 就无法序列化到攻击者已篡改的相邻池对象中。这可以防止管道队列损坏，从而防止数据泄漏、任意读/写攻击和令牌交换。
结论
CVE-2026-42980 并非普通的 WMI 漏洞。其易受攻击的函数是
nt!WmipQueryAllDataMultiple` nt!WmipQuerySingleMultipleWMI_ 0x228130...
项目地址：
https://github.com/G4sp4rCS/CVE-2026-42980-POC/tree/main
END
公众号内容都来自国外平台-所有文章可通过点击阅读原文到达原文地址或参考地址
排版 编辑 | Ots 小安
采集 翻译 | Ots Ai牛马
公众号 | AnQuan7 (Ots安全)
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论