windows - 为什么在内核模式下调用 ZwCreateKey 似乎可以绕过 Windows 安全？

Question

与我合作的团队最近面临着使我们的软件与第三方虚拟化软件兼容的挑战。该软件使用内核驱动程序来执行 Windows native 注册表 API(ZwCreateKey 等)的 Hook 。它通过 Hook Ntdll 中的调用来工作。我们的软件也相当低级，在某些情况下需要访问真实注册表而不被 Hook 。

我们正在探索使用我们自己的内核驱动程序调用 ZwCreateKey 等的可能性，以我们的名义绕过它们的 Hook 。这实质上意味着创建一个 NT Legacy 驱动程序和一个提供我们自己的 native 注册表功能的用户模式库。库和驱动程序非常简单，我们只需使用 IOCTL 将 ZwCreateKey 等所有参数传递到我们的驱动程序中，然后调用内核版本的调用并返回结果。

该方法运行良好，我们现在似乎拥有一个在虚拟化时读取/写入真实注册表的系统。唯一的问题是我们的新系统似乎在注册表对象上规避了 Windows 安全性。

ZwCreateKey 采用如下访问掩码:

NTSTATUS ZwCreateKey(
  __out       PHANDLE KeyHandle,
  __in        ACCESS_MASK DesiredAccess,
  __in        POBJECT_ATTRIBUTES ObjectAttributes,
  __reserved  ULONG TitleIndex,
  __in_opt    PUNICODE_STRING Class,
  __in        ULONG CreateOptions,
  __out_opt   PULONG Disposition
);

我的理解是，虽然我们现在在内核模式下运行，但我们仍然拥有用户 token 的上下文。这应该意味着 ZwCreateKey 的内核版本将失败，就像访问掩码测试失败时用户会遇到的那样。实际发生的情况是，即使使用有限的 token ，当我们的驱动程序被调用时，它也能够在受限用户调用时在受限部分 HKLM 中创建 key 。是什么赋予了？我们应该自己执行 ACL 检查吗？我们是否需要做一些事情来限制我们在内核模式下的特权？非常感谢任何帮助。

Answer 1

检查 this解释。基本上，用户模式 ​​(ntdll) 中的 Nt/Zw 是同一件事——它们在实际执行操作之前首先执行广泛的检查。而当从内核模式调用 Zw 函数时(就像设备驱动程序的情况一样)，这些检查被忽略了，因为默认情况下假定来自内核模式组件(例如驱动程序)的信息是可信的