SmmExploit

这是针对 CVE-2021-26943 的一份报告和利用代码，该漏洞是华硕 UX360CA BIOS 版本 303 中存在的内核到 SMM 本地权限提升漏洞。该问题已在 版本 304 中修复。

问题描述

摘要

UX360CA BIOS 版本 303 包含 3 个存在漏洞的模块，允许具有 ring0 权限的攻击者覆盖几乎任意物理内存（包括 SMRAM），并在 SMM 中执行任意代码。

这些模块的标识如下：

这些模块来自 AMI（BIOS 供应商），也可能出现在其他 OEM 的 BIOS 中。

漏洞详情

存在漏洞的模块及对应的 SMI 为：UsbRt (0x31)、SdioSmm (0x40) 和 NvmeSmm (0x42)。所有这些 SMI 处理程序都会读取物理内存地址 0x40E 以获取要操作的目标地址，并且在出错时会向该地址写入一个字节，即使该地址位于 SMRAM 中也是如此。

例如，SdioSmm 的 SMI 处理程序如下所示：

EFI_STATUS
EFIAPI
SdioSmm_SwSmi_40h(
  EFI_HANDLE  DispatchHandle,
  CONST VOID  *Context,
  VOID        *CommBuffer,
  UINTN       *CommBufferSize
  )
{
  // ...
  struct_v0 *userControlled = *(0x10 * MEMORY[0x40E] + 0x104);
  if ( EFI_ERROR(ValidateBufferIsOutsideSmram(userControlled, sizeof(struct_v0)))
    || userControlled->Offset0_FunctionCode >= 4 )
  {
    userControlled->Offset2 = 7;
  }
  else
  {
    // ...
  }
  return EFI_SUCCESS;
}

此问题似乎与 INTEL-SA-00057 相同，后者在 Aptiocalypsis 中有详细描述。然而，UX360CA 的 BIOS 版本 303 并未包含针对这些问题的修复。

利用方法

这使得攻击者能够通过以下步骤，在具有对物理内存和 OUT 指令（即 ring0 权限）的写入访问权限的情况下，覆盖 SMRAM 的内容：

1. 确保物理地址 0x40e 为零（通常情况下已经为零）
2. 在物理地址 0x104 处写入一个 SMRAM 地址，例如 0x88400000
3. 触发 SMI 0x40
4. 0x88400000+2 被更新为 0x7。

这可用于实现 SMM 中的任意代码执行，具体步骤如下：

1. 在 SMRAM 中找到系统管理服务表（SMST）的地址，步骤如下：
   1. 从 HKLM\HARDWARE\RESOURCEMAP\System Resources\Loader Reserved 的 .Raw 值内容中获取 UEFI 运行时代码的物理地址范围。
   2. 通过在该地址范围内扫描 'smmc' 签名来找到 SMM_CORE_PRIVATE_DATA 的地址。
   3. SMM_CORE_PRIVATE_DATA 在偏移量 30h 处包含指向 SMST 的指针。
2. 使用上述写入原语覆盖 SMST 偏移量 d0h 处的 SmmLocateProtocol 函数指针。该值被更新为 0x07070707。
3. 在物理内存 0x07070707 处写入 shellcode。
4. 触发另一个调用 Smst->SmmLocateProtocol 的 SMI，例如 SMI 0xdf。位于 0x07070707 的 shellcode 将在 SMM 中执行。

SMM 中的任意代码执行将允许攻击者绕过内核和虚拟机管理程序的安全措施（如 HVCI），如 另一份 SMM 漏洞报告 所示，并通过更新 SPI 闪存（BIOS）的内容建立持久化。

概念验证（PoC）

附带的演示项目展示了成功的利用过程，并转储了仅在 SMM 中可访问的 MSR 内容以及 EPTP 的物理地址。它还修改了 Hyper-V 虚拟机管理程序的 CPUID VM-exit 处理代码，以返回一个更改后的虚拟机管理程序供应商字符串。

该 PoC 已在 Windows 内部版本 18362.1256 上测试，无论是否启用 HVCI。

成功利用的录制视频可在 YouTube 上找到。

测试说明

1. 在 Visual Studio 2019 中打开 demo.sln
2. 为 Debug 或 Release 版本构建解决方案
3. 将编译后的 demo.sys 复制到目标系统（例如 C:\users\user\desktop\demo.sys）

在目标系统上，

1. 在 BIOS 中禁用安全启动，然后重新启动
2. 启用测试签名模式，然后重新启动
   root@kitploit:~

   > bcdedit /set testsigning on
   

3. 创建服务以加载 demo.sys
   root@kitploit:~

   > sc create demo type= kernel binPath= C:\users\user\desktop\demo.sys
   

4. 启动 DebugView 并在 "Capture" 菜单中启用 "Capture Kernel"。
5. 启动演示
   root@kitploit:~

   > sc start demo
   

6. 如果成功，DebugView 将显示 SMM 相关 MSR 的值。
   root@kitploit:~

   [+] ReportSmramRange: TSEG implied SMRAM: 0x88400000 - 0x88800000
   [-] ReportSmramRange: Exception occurred while accessing SMRR MSR : c0000096
   [+] FindSystemManagementServiceTable: SMM core found at 0x87f1b390 in RT Code
   [+] FindSystemManagementServiceTable: SMST found at 0x887fa710 in SMRAM
   [+] ExploitSmm: Patched SMST->SmmLocateProtocol in SMRAM
   [+] ExploitSmm: Placed SMM shell code
   [+] ExploitSmm: Triggered SMM exploit
   [+] DumpSmmExploitOuput: IA32_SMBASE             = 0x887cd000
   [+] DumpSmmExploitOuput: MSR_SMM_FEATURE_CONTROL = 0x1
   [+] DumpSmmExploitOuput: MSR_SMM_MCA_CAP         = 0xc00000000000000
   [+] DumpSmmExploitOuput: EPT pointer             = 0x10a72001e
   [+] DumpSmmExploitOuput: Patched Hv address      = 0x1004382f0
   [+] ExploitSmm: Successfully executed shell code in SMM. Failing DriverEntry to unload itself
   DriverEntry failed 0xc0000120 for driver \REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\demo
   

修复方案

修复方法是完全避免在用户控制的内容指向 SMRAM 内部时使用它，如下所示。

{
  // ...
  struct_v0 *userControlled = *(0x10 * MEMORY[0x40E] + 0x104);
  if (!EFI_ERROR(ValidateBufferIsOutsideSmram(userControlled, sizeof(struct_v0))))
  {
    if (userControlled->Offset0_FunctionCode < 7 )
    {
      // ...
    }
    else
    {
      userControlled->Offset2 = 7;
    }
  }
  return EFI_SUCCESS;
}

注意事项

对虚拟机管理程序的保护缺失

该修复完全遵循了当前的行业最佳实践，并防止了导致 SMRAM 损坏的混淆代理攻击。

然而，请注意它没有考虑虚拟机管理程序内存区域。拥有虚拟机管理程序加载或使用的物理内存地址知识的攻击者，仍然可以请求 SMI 覆盖虚拟机管理程序代码或数据，从而实现虚拟机管理程序损坏。

这是一个普遍存在且长期存在的问题，甚至是一个设计层面的问题。

缺乏纵深防御

已报告的问题得到了解决，但在执行纵深防御策略方面存在一些问题。

例如，SMM 页表是恒等映射的，具有完全可读、可写和可执行权限，并且 SMM_Code_Chk_En 功能不可用。这使得利用变得简单。我还注意到 SMM 通信缓冲区没有像 EDK2 中那样 使用 SmmIsBufferOutsideSmmValid() 进行验证，尽管我没有找到可利用的 SMI。

我认为这些是 OEM 和许多 BIOS 版本中的常见问题。我要指出的是，如果你使用的是任何 OEM 的旧型号，其 BIOS 的安全性很可能远低于你的预期，即使使用了最新的 BIOS 版本。

改进方向

这些问题不会很快消失，但我很高兴看到业界正在通过减少 SMM 权限来寻求架构上的解决方案。以下是一些你可以查阅的相关工作和文章：

• 平台运行时机制（PRM）
  • 演示文稿（开源固件会议 2020）
  • 规范（uefi.org）
  • 实现（edk2-staging）
• 系统管理模式深度剖析：SMM 隔离如何强化平台
• System Guard 的系统要求

时间线

以下是一些关键事件。

• 2020年12月31日 - 我报告了该漏洞
• 2021年1月5日 - 华硕确认收到报告
• 2021年1月18日 - 华硕向我发送了修复后的 BIOS 版本进行测试
• 2021年1月20日 - 我确认修复并回复
• 2021年1月25日 - 华硕确认收到我的回复
• 2021年3月21日 - 华硕公开了修复，版本 304
• 2021年3月29日 - 华硕发布了针对 CVE-2021-26943 的 安全公告

最后，衷心感谢华硕团队保持了密切和透明的沟通渠道❤ 整个过程虽然不快，但几乎没有令人沮丧的地方。