KASLR泄漏限制

近年来，微软一直致力于缓解漏洞类别和利用技术。在最新的Windows版本中，出现了一项新变化——限制内核地址向用户模式的泄漏，这给针对Windows内核的攻击者带来了重大挑战。几乎所有内存漏洞利用都需要攻击者获取某些内核地址泄漏，以了解要读取/写入/溢出/破坏的地址。这些地址可能是ntoskrnl.exe或其他内核驱动程序的地址，也可能是攻击者目标的某个对象地址。

直到最近，获取这些地址还非常容易（对于任何以中等完整性级别或更高权限运行的用户）。只需调用几个已知的Windows API之一即可。

但从Windows 11/Windows Server 2022 24H2版本开始，这些API将不再泄漏任何内核地址，除非请求进程已启用SeDebugPrivilege——这是一个强大的特权，仅适用于管理员进程且默认不启用。

新的权限检查机制

此检查通过传递给ExIsRestrictedCaller的新标志实现：

ExIsRestrictedCaller在内核中的多个位置被调用，以检查进程是否应获得对资源的访问权限或被允许执行操作。例如，这用于限制以低或不受信任完整性级别运行的进程调用返回内核地址的API。现在，此API还会检查进程是否启用了SeDebugPrivilege，并使用结果设置RestrictKernelAddressLeaks参数（名称由我选择，因为参数名称未公开）并将其返回给调用者。

然后，调用者使用此参数决定可以向用户模式调用者返回哪些内核数据。

实际应用示例

例如，当使用SystemModuleInformation类调用NtQuerySystemInformation（调用内部的ExpQuerySystemInformation）时，会调用ExIsRestrictedCaller来确定调用者可以接收哪些数据。输出参数随后传递给ExpQueryModuleInformation：

在ExpQueryModuleInformation内部，RestrictKernelAddressLeaks参数用于决定函数是否为系统中加载的每个内核模块填充DllBase字段：

如果设置了该参数（意味着进程未启用SeDebugPrivilege），进程仍能接收有关已加载内核模块的信息。但这些信息将不包含这些模块的基地址——该字段将被设置为0。

影响范围

此检查在所有已知向用户模式调用者泄漏内核地址的其他API中均被执行。在所有情况下，对于以中等IL或更高权限运行的调用者，查询都会成功，但通常包含内核地址的字段将保持为空。

现在限制内核地址泄漏的完整API列表包括： [表格ID=1 /]

结论与展望

这些API是泄漏内核地址的唯一方法吗？KASLR泄漏终于消失了吗？当然不是。但更多内容将在另一篇博客文章中讨论 🙂

相关研究主题：

• 使用LiveCloudKd进行安全内核研究
• 系统崩溃故障排除
• 调查过滤器通信端口
• KASLR绕过的终结？
• 理解新缓解措施：模块篡改保护
• Windows 11上的完整读/写利用原语
• HyperGuard第3部分——更多SKPG扩展
• 动态分析实践