研究员学习Hyper-V时意外挖出微软隐藏BUG：CVE-2024-21305

导语：安全研究员Satoshi Tanda本来只是想搞清楚微软Hyper-V虚拟机管理程序的工作原理，结果却在UEFI中发现了一个HVCI（虚拟机管理程序保护的代码完整性）严重漏洞——CVE-2024-21305。这个漏洞允许在启用HVCI保护的内核模式下执行任意代码，相当于彻底绕过了Windows内核最核心的安全防线。

一、推文引发热议：学习如何变成挖洞

Twitter用户@cr3ghost发布的一则推文在Windows安全圈引发了广泛关注。推文介绍称，Satoshi Tanda在研究微软Hyper-V虚拟机管理程序与HVCI实现的工作原理时，作为”副产品”意外发现了这些系统中的BUG。

这则推文获得了431个点赞和72次转发，评论区的安全研究员们纷纷感叹：能理解如此庞大系统的内部机制并发现隐藏BUG，这本身就说明了底层技术的复杂程度。BitValentine评论称：”一个人能在Hyper-V这样庞大的系统中挖出BUG，这突显了这些技术的复杂程度。学习和实验能带来意想不到的突破——想象一下如果有更多人采取这种方法会怎样？”

（图片来源：Satoshi Tanda技术博客）

二、事件背景：研究Hyper-V如何挖出微软BUG

根据Tanda发表的详细技术博客文章，这一发现是他开发hvext.js（用于研究Intel处理器上Hyper-V实现的WinDbg扩展）的副产品之一。通过这个扩展，他在几台设备上转储了EPT（扩展页表），以更好地理解HVCI的实现。其中一台设备显示了可读、可写、可内核模式执行的客户机物理地址（GPA）。

当HVCI启用时，这类GPA本不应该存在——因为它将允许在内核模式下生成并执行任意代码。最终，在他手中的7台Intel设备中，他发现有3台存在这个问题，涉及从第6代到第10代的处理器。

三、技术细节：CVE-2024-21305漏洞剖析

3.1 漏洞危害

CVE-2024-21305是一个非安全的HVCI配置漏洞，在2024年1月9日的Windows更新中披露并修复。该漏洞允许任意内核模式代码执行，等同于在根分区中完全绕过HVCI保护。

（图片来源：Satoshi Tanda技术博客）

3.2 利用过程

Tanda指出，利用这个问题进行验证非常简单，因为这些RWX（可读可写可执行）GPA在重启或启用测试签名时不会改变。他编写了一个驱动程序，将所选线性地址重新映射到其中一个RWX GPA上，并在那里放置shellcode，最终成功执行了shellcode。如果HVCI按预期工作，这个PoC驱动程序本应该无法写入shellcode并导致蓝屏崩溃。

3.3 部分根因分析

Tanda对为什么只在部分设备上出现这个问题感到好奇，并开始调查这些RWX GPA到底是什么。在运行时，这些GPA的内容都显示为零，RamMap（Windows内存分析工具）显示它位于NTOS管理的内存之外。在Winload调试会话中转储内存时，它们仍然大部分为零。在UEFI Shell阶段也是如此。

此时，他意识到这些可能是UEFI保留区域。首先，他发现这些RWX GPA是保留区域的一部分，但与UEFI Shell的memmap命令输出并不完全匹配。很快，他发现这些区域恰好与DMAR ACPI表中保留内存区域报告（RMRR）结构报告的范围相对应。

3.4 技术原理：Intel VT-d与RMRR

为了理解这个BUG，我们需要了解Intel VT-d（Intel Virtualization Technology for Directed I/O）技术。该技术规范由Intel维护，旨在保护设备对属于另一个虚拟机或保留给宿主机虚拟机管理程序/操作系统的内存的访问。

DMAR ACPI表由BIOS报告，描述IOMMU相关信息。其中一个关键结构是RMRR（Reserved Memory Region Reporting）。对于某些设备（如用于调试的网络控制器、用于传统键盘仿真的USB控制器），无论IOMMU是否设置，都应始终能够执行DMA，因此使用RMRR结构来描述DMA应始终可行的内存区域。

Intel手册中关于RMRR结构有两个重要概念：

• BIOS应在UEFI内存映射中把RMRR描述的物理内存报告为保留
• 当操作系统启用DMA重映射时，应使用”身份映射”（identity mapping）为RMRR描述的物理内存设置二级地址转换结构，并设置读/写（RW）权限

四、漏洞触发条件

在某些有BUG的固件中，没有满足第一个要求——也就是说，虚拟机管理程序和安全内核都不知道UEFI内存映射中的这个内存范围。

在启动时，Hypervisor初始化其内部状态，创建根分区，并分多个阶段执行IOMMU初始化。在AMD64机器上，其中一个阶段需要解析RMRR。需要注意的是，虚拟机管理程序此时并不知道系统是否将启用VBS/HVCI，因此除了对范围应用完整的身份映射（即RWX保护）之外，别无选择。

当安全内核稍后启动并确定应启用HVCI时，它会将新的”默认VTL权限”设置为RW（但不执行），并通过设置公共的HvRegisterVsmPartitionConfig合成MSR来通知虚拟机管理程序。当目标分区的VTL 1设置默认VTL保护并写入HvRegisterVsmPartitionConfig MSR时，会导致虚拟机管理程序发生VMEXIT，该管理程序会循环遍历UEFI内存映射中描述并在VTL 0 SLAT中映射的每个有效客户机物理帧，移除”执行”权限位。

关键问题在于：在有BUG的固件中，RMRR没有设置在UEFI内存映射中，导致该描述区域的”执行”保护保持开启状态，从而产生HVCI违规。

五、修复方案

微软从两个方面修复了这个问题：

1. 修复固件：在微软发布的所有商用设备中修复固件，强制将RMRR内存区域包含在UEFI内存映射中
2. 虚拟机管理程序的兼容性修复：由于架构要求RMRR内存区域必须使用身份映射在IOMMU中映射（通过前述的层次地址转换结构），具有读/写访问权限（但没有X-执行权限），因此决定执行一些兼容性测试，看看如果虚拟机管理程序通过剥离X位来保护SLAT中所有RMRR内存区域的初始PFN会发生什么。结果显示几乎零兼容性问题，因此微软决定增加保护力度，默认情况下在所有系统上移除所有RMRR内存区域的X权限，即使固件有BUG也能提高保护效果。

六、影响与意义

这一漏洞的修复已于2024年1月9日发布，但并非所有设备都受此问题影响。然而，你可以通过检查UEFI Shell的memmap命令未将精确的RMRR内存区域显示为Reserved来识别有漏洞的设备。

Tanda的工作展示了一个重要的安全研究原则：通过深入学习和理解系统的工作原理，安全研究员不仅能够掌握防御技能，还能在意外中发现关键漏洞。他的博客文章涵盖了Intel VT-rp（Intel构建的用于对抗基于EPT的Hook的硬件防御）、内核影子栈、SMM隔离、Hyper-V强制安全策略，以及他如何在UEFI中追踪HVCI BUG。

七、Tanda的开源项目贡献

Tanda的开源项目包括：

• DdiMon：用于隐蔽EPT内核API监控的虚拟机管理程序
• UEFI虚拟机管理程序：可以引导完整操作系统的UEFI虚拟机管理程序
• 针对Intel和AMD的最小虚拟机管理程序
• 完整的虚拟机管理程序开发培训课程：面向安全研究人员的从零开始构建虚拟机管理程序的培训课程

值得注意的是，DdiMon和HyperPlatform多年来一直被游戏作弊者分叉和改造，作为野外EPT-based Hook的基础。出于研究目的构建的代码竟然成为了整个作弊生态系统的支柱。

对于学习虚拟机管理程序开发、Windows内核或平台安全的人来说，Tanda的工作是最好的起点。

八、安全研究启示

这一事件给安全研究社区带来了几点重要启示：

1. 深入学习的价值：Tanda的发现源于他对系统工作原理的深入学习，而非主动寻找漏洞
2. 系统复杂性的双刃剑：微软这样的复杂系统即使经过严格的内部测试，仍可能存在隐藏的BUG
3. 硬件与固件的协同挑战：该BUG涉及BIOS固件与操作系统虚拟机管理程序的协作，这种跨层问题最容易出现
4. 持续安全审计的重要性：即便如HVCI这样的成熟安全机制也需要持续的审计和改进

原文出处：

• 推文：https://x.com/cr3ghost/status/2069722199137861962
• 技术博客：https://tandasat.github.io/blog/2024/01/15/CVE-2024-21305.html
• PoC代码：https://github.com/tandasat/CVE-2024-21305
• Microsoft公告：https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21305