Tyranid's Lair：专为1%人群设计的静默漏洞缓解机制
随着Windows 10加速更新周期，新功能被不断引入，特别是那些用于缓解设计缺陷API或易滥用行为的特性。但多数缓解措施存在严重问题：它们通常未文档化，或至少未通过常规Win32 API公开。这意味着微软可以高枕无忧地保护自家代码安全，却让第三方开发者陷入困境。
未文档化的缓解案例
典型的静默缓解案例是OBJ_IGNORE_IMPERSONATED_DEVICEMAP和OBJ_DONT_REPARSE这两个OBJECT_ATTRIBUTE标志位——它们的文档化花费了5年时间，而这仅仅是因为我提出了相关需求。值得注意的是，这些标志仅在使用系统调用API时有效（别忘了这些API本身也只有部分文档）。
NtLoadKey3的发现
在Windows 10 2004（这个版本命名真是令人困惑）中，经Alex Ionescu提醒，我发现微软又引入了一个仅通过未文档化系统调用实现的缓解措施——NtLoadKey3。根据@FireF0X的信息，该补丁已被反向移植到所有受支持系统，却未作任何公告。
系统调用的演进
- NtLoadKey：原始版本
- NtLoadKey2：XP时代引入，添加标志位
- NtLoadKeyEx：引入可信配置单元支持，防御跨配置单元符号链接攻击
- NtLoadKey3：最新版本，采用全新设计模式
（微软的版本编号逻辑令人费解：2→Ex→3）
漏洞本质与修复
传统注册表加载操作（需SeRestorePrivilege权限）存在设计缺陷：当从用户可访问位置（如用户配置文件）加载配置单元时，攻击者可通过符号链接技巧将日志文件写入任意位置。更严重的是，主配置单元文件的安全描述符会被复制到日志文件。
NtLoadKey3通过新增参数解决该问题：
typedef struct _KEY_LOAD_HANDLE {KEY_LOAD_ENTRY_TYPE Type;HANDLE Handle;
} KEY_LOAD_HANDLE;NTSYSCALLAPI NTSTATUS NTAPI NtLoadKey3(_In_ POBJECT_ATTRIBUTES TargetKey,_In_ POBJECT_ATTRIBUTES SourceFile,_In_ ULONG Flags,_In_ PKEY_LOAD_HANDLE LoadEntries,_In_ ULONG LoadEntryCount,_In_opt_ ACCESS_MASK DesiredAccess,_Out_opt_ PHANDLE RootHandle,_In_ PVOID Unused
);
新机制允许指定访问令牌——权限检查使用调用方令牌，而危险文件操作则使用模拟用户令牌。用户配置文件服务现已采用此机制加载配置单元。
微软的沟通困境
在这个号称"开放共享"的新微软时代，关键安全特性仍缺乏透明沟通。显然，微软更热衷于将Wayland引入WSL2或强推新API集，而非完善此类基础安全组件的文档工作。
更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）
公众号二维码
