CVE-2026-50416-writeup-and-poc

CVE-2026-50416: Windows 11 KASLR 绕过

偏移量因版本而异，但路径很简单：

PoC 对返回的地址调用 VirtualQuery，并记录映射区域及其保护属性。到目前为止一切正常。只读的桌面堆映射是 Win32k 的正常行为。

问题出现在映射区域 256 字节之后。

偏移量 0x100 处的指针

主 PoC 从映射堆中读取一个 QWORD：

该值通过了在测试系统上对内核虚拟地址的基本检查：

• 规范高位
• 八字节对齐
• 不是 PoC 过滤掉的已知哨兵值之一
• 在窗口创建和销毁期间保持稳定
• 在同一桌面的测试进程中相同
• 重启后不同
• 在另一个桌面上不同

稳定性测试创建 STATIC、BUTTON 和 EDIT 窗口，在创建前读取该值，在窗口存在时再次读取，销毁窗口后第三次读取。

三次读取返回的值相同。窗口分配活动没有移动它。这种行为与桌面堆元数据中的字段一致，而非短生命周期对象的指针。

跨进程属性同样重要。附加到同一桌面的两个进程观察到相同的泄漏值，因为它们查看的是同一个桌面堆。重启后，KASLR 为会话分配了新地址。放置在另一个桌面上的子进程观察到另一个指针，因为该桌面拥有另一个堆。

这赋予了该泄漏一个有用的身份特征：

恢复内核桌面堆基址

在测试版本上，泄漏的指针位于 PoC 使用的内核桌面堆基址上方 0x40 字节处：

使用记录的会话值：

这种关系因版本而异。对于测试期间使用的版本，它提供了下一步所需的内核侧锚点。

一个指针已经很有用。一个选定对象的地址则有用得多。

通过 gSharedInfo 解析窗口对象

user32.dll 导出了 gSharedInfo，它暴露了 USER 句柄条目列表及每个条目的大小：

一个 HWND 包含 USER 句柄表的索引。PoC 取句柄的低 16 位，遍历到匹配的条目，并读取存储在那里的桌面堆偏移量。

相同的偏移量在两个映射中标识同一个对象：

因此完整的计算过程是：

PoC 创建六个窗口类，并对每个类执行计算：

• STATIC
• BUTTON
• EDIT
• LISTBOX
• SCROLLBAR
• COMBOBOX

对于每个对象，它打印 HWND、句柄索引、用户模式对象地址、堆偏移量和内核地址。

这部分将披露从松散的内核指针转变为测试桌面堆上选定 USER 对象的地址预言机。

为什么沙箱测试很重要

桌面堆通过共享映射到达。完整性级别和 AppContainer 限制不会为每个进程重写该映射的内容。如果进程收到桌面堆，它也会一并收到 0x100 处的 QWORD。

沙箱 PoC 在多种上下文中启动子进程，并让每个子进程从自己的 TEB 和自己的桌面堆映射中读取该值。

前五个子进程附加到默认桌面并返回相同的地址。备用桌面子进程返回另一个地址，因为它收到了另一个桌面堆。

子进程输出采用紧凑格式，以便父进程比较结果：

更严格的辅助程序还记录令牌状态和能力计数：

重要的细节不是子进程可以调用特殊的 Win32k API。它不需要。一旦映射存在，泄漏就是一次普通的用户模式内存读取。

无需创建窗口

另一个辅助程序在不调用 CreateWindow 的情况下执行读取。

它检查桌面堆指针，读取 desktop_heap[0x100]，显式加载 user32.dll，再次检查映射，并且始终不创建窗口。另一个类似渲染器的子进程加载 user32.dll，执行相同的读取，并在不创建任何窗口的情况下退出。

有用的结果很直接：

泄漏属于桌面堆映射本身，而非攻击进程创建的窗口。

类似渲染器的子进程

supporting_proof_remote_trigger.c 创建一个零请求能力的低完整性 AppContainer 子进程。该子进程只做少量工作：

记录的输出：

这证明了从类似渲染器的令牌配置中进行读取。一个已经在该类进程中提供本机代码执行的独立浏览器内存损坏漏洞，在读取此桌面堆指针之前不需要另一个信息泄露。

映射中还能看到什么

一旦我有了可靠的指针，我就扫描了映射区域，看看还有什么其他内容。

其他内核形态的值

扫描器每次运行发现六到十个额外的唯一 QWORD 值，这些值通过了相同的规范地址和对齐检查。确切数量随桌面活动而变化。偏移量 0x100 是稳定的主要泄漏，但它不是映射中唯一具有内核地址形态的值。

其他进程的窗口标题

敏感数据辅助程序使用 EnumWindows 枚举顶层窗口，收集其所属 PID 和标题，然后在桌面堆映射中搜索相同的标题作为 UTF-16 字符串。

在记录的运行中，它发现了属于其他进程的二十个唯一标题。示例包括浏览器标签页、Discord、Explorer、Spotify 和系统托盘窗口。

程序仅在两个条件都成立时才打印标题：

1. 该字符串存在于映射的桌面堆区域中。
2. EnumWindows 报告一个具有该标题且所属 PID 与测试进程不同的窗口。

这使得输出易于验证，而不是依赖在内存中发现的随机可打印字符串。

进程 ID 出现

辅助程序还扫描映射中的 DWORD 值。仅当满足以下条件时才计数一个值：

1. 它看起来像合理的 PID。
2. OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION) 对其成功。
3. 该 PID 还拥有一个由 EnumWindows 找到的窗口。

记录的运行发现了 605 个匹配的 DWORD 出现。这是堆中出现的次数，而非 605 个唯一进程。同一个 PID 可以出现多次。

密码编辑文本

辅助程序创建一个带 ES_PASSWORD 的 EDIT 控件，将其文本设置为 SecretPassword123，并在映射区域中搜索 SecretP 前缀。在测试运行中未找到。

因此，映射暴露了标题、PID 出现和内核形态的值，而测试的密码字符串没有出现在那里。

泄漏在利用过程中改变了什么

对于 Win32k 内存损坏漏洞，知道对象存在与知道它在内核内存中的位置是不同的。

没有该披露，攻击者必须处理未知的桌面堆基址和未知的对象地址。有了该披露，地址侧变为：

对于选定的 HWND，攻击者现在在测试版本上拥有了对应的内核桌面堆地址。这有助于：

• 通过堆活动跟踪目标对象
• 将预期对象与相邻分配区分开来
• 计算单独的读取、写入或损坏原语使用的地址
• 检查堆整形是否产生了预期的布局
• 从 Win32k 利用链中消除桌面堆地址猜测

该泄漏解决了地址问题。堆整形、对象替换和内存损坏原语仍然是利用的独立部分。

这种划分很重要。KASLR 不会阻止内存损坏。它使可靠的目标定位更加困难。这个 QWORD 消除了 PoC 使用的桌面堆区域的不确定性。

复现

测试环境

文件

• kaslr_bypass_poc.c：主泄漏和窗口地址解析 PoC
• kaslr_sandbox_proof.c：中 IL、低 IL、AppContainer、LPAC 配置、低 IL AppContainer 和备用桌面测试
• supporting_proof_no_window.c：不创建窗口的读取
• supporting_proof_no_caps_lpac.c：零能力 AppContainer 和 LPAC 配置
• supporting_proof_sensitive_data.c：标题、PID 出现、额外指针扫描和密码字段检查
• supporting_proof_exploitability.c：六个窗口类和内核地址计算
• supporting_proof_remote_trigger.c：类似渲染器的低 IL AppContainer 子进程
• compile.bat：构建菜单

编译

运行：

从菜单中选择目标。

主 PoC 也可以直接从 Visual Studio 开发者命令提示符编译：

验证指针

不重启运行主 PoC 两次：

desktop_heap + 0x100 处的指针在两次运行中应相同。

打开第二个终端，从同一桌面的另一个进程运行它。该值应再次匹配。

重启并重复。该值应发生变化。

运行沙箱测试

该测试启动每个子进程，捕获其输出，并比较泄漏值。默认桌面上的子进程应报告相同的值。备用桌面子进程应报告不同的值。

运行聚焦辅助程序

每个辅助程序隔离结果的一个部分，以便无需通读完整 PoC 的输出即可复现。

修复

用户模式映射不应包含原始的内核虚拟地址。

最小的修复是在页面在用户模式中可见之前清理桌面堆头字段。Windows 已经对其他桌面堆指针字段使用不透明的 0x6000000000 值，因此如果用户模式仍然需要该字段，可以在此处使用相同风格的替换。

如果用户模式不需要头页面，更干净的修复是不在共享映射中暴露该页面。

回归测试很简单：在中 IL、低 IL、AppContainer 和 LPAC 配置下创建进程，映射桌面堆，并拒绝在用户可见的头中找到的任何规范内核地址。

结语

整个链条始于对只读映射的一次普通读取：

该 QWORD 标识了内核桌面堆。gSharedInfo 提供每个对象的偏移量。两者结合，在测试版本上将用户模式 HWND 转换为对应的内核地址。

这里没有隐藏复杂的触发器。Windows 将桌面堆放在用户模式可以读取的位置，然后在共享的部分中留下了一个内核指针。

一个 QWORD 就足够了。