SmmExploit

これは、ASUS UX360CA BIOSバージョン303におけるカーネルからSMMへのローカル権限昇格の脆弱性であるCVE-2021-26943に関するレポートとエクスプロイトです。この問題はバージョン304で修正されました。

問題の説明

概要

UX360CA BIOSバージョン303には、ring0権限を持つ攻撃者がSMRAMを含むほぼ任意の物理メモリを上書きし、SMM内で任意のコードを実行できるようにする3つの脆弱なモジュールがあります。

これらのモジュールは以下のように識別できます:

これらのモジュールはAMI（BIOSベンダー）製であり、他のOEMのBIOSにも存在する可能性があります。

脆弱性

脆弱なモジュールと対応するSMIは、UsbRt（0x31）、SdioSmm（0x40）、NvmeSmm（0x42）です。これらのSMIハンドラはすべて、物理メモリアドレス0x40Eを読み取って処理対象のアドレスを取得し、エラー時にはそのアドレスがSMRAMであっても1バイト書き込みます。

たとえば、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;
}

この問題は、Aptiocalypsisとして詳しく説明されているINTEL-SA-00057と同一であると思われます。ただし、UX360CA用のBIOSバージョン303にはこれらの修正は含まれていません。

エクスプロイト

これにより、物理メモリへの書き込みアクセスとOUT命令を持つ攻撃者（つまりring0権限）は、以下の手順でSMRAMの内容を上書きできます:

1. 物理アドレス0x40eがゼロであることを確認する（おそらくすでにゼロです）
2. SMRAMのアドレス（例: 0x88400000）を物理アドレス0x104に書き込む
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に書き込む
4. SMI 0xdfなど、Smst->SmmLocateProtocolを呼び出す別のSMIをトリガーする。0x07070707のシェルコードがSMMで実行される

SMMでの任意コード実行により、攻撃者は別のSMM脆弱性レポートで実証されているように、HVCIなどのカーネルやハイパーバイザーによるセキュリティ対策を回避し、SPIフラッシュ（BIOS）の内容を更新して永続性を確立できます。

概念実証（PoC）

添付のデモプロジェクトは、エクスプロイトの成功を実証し、SMMでのみアクセス可能なMSRの内容とEPTPの物理アドレスをダンプします。また、Hyper-VハイパーバイザーのCPUID VM-Exit処理コードを変更して、改変されたハイパーバイザーベンダー文字列を返すようにします。

PoCは、HVCIを有効にした場合と有効にしない場合の両方で、Windowsビルド18362.1256上でテストされています。

エクスプロイト成功の録画は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の破損につながるconfused deputy攻撃を防ぎます。

ただし、この修正はハイパーバイザーのメモリ領域を考慮していないことに注意してください。ハイパーバイザーがロードされている、または使用されている物理メモリアドレスを知っている攻撃者は、SMIにハイパーバイザーのコードやデータの上書きを要求して、ハイパーバイザーを破損させることが依然として可能です。

これは広く見られる、長年にわたって存在する、設計レベルにまで及ぶ問題です。

多層防御の欠如

報告された問題は解決されましたが、多層防御戦略の実行という点ではいくつかの問題がありました。

たとえば、SMMページテーブルはフルの読み取り・書き込み・実行権限を持つアイデンティティマッピングであり、SMM_Code_Chk_En機能は利用できませんでした。これらにより、エクスプロイトは自明なものになりました。また、EDK2にあるように、SMM通信バッファがSmmIsBufferOutsideSmmValid()で検証されていないことにも気付きましたが、悪用可能なSMIは見つかりませんでした。

これらは、OEMや多くのBIOSバージョンに共通する問題であると私は考えています。どのOEMの古いモデルを使用している場合でも、そのBIOSは最新のBIOSバージョンであっても、あなたが望むほど安全である可能性は低いということを指摘しておきます。

改善

これらの問題はそう遠くないうちに解決されることはないでしょうが、業界がSMMの特権を削減することによるアーキテクチャレベルの解決に取り組んでいるのを見るのは嬉しいことです。以下は、確認できる取り組みや記事の一部です:

• Platform Runtime Mechanism (PRM)
  • プレゼンテーション（Open-Source Firmware Conference 2020）
  • 仕様（uefi.org）
  • 実装（edk2-staging）
• System Management Modeの詳細: SMM分離がどのようにプラットフォームを強化するか
• System Guardのシステム要件

タイムライン

主なハイライトは以下のとおりです。

• 2020-12-31 - 脆弱性を報告しました
• 2021-01-05 - ASUSがレポートを確認しました
• 2021-01-18 - ASUSからテスト用の修正版BIOSが送付されました
• 2021-01-20 - 修正を確認して返信しました
• 2021-01-25 - ASUSが私の返信を確認しました
• 2021-03-21 - ASUSが修正を公開しました（バージョン304）
• 2021-03-29 - ASUSがCVE-2021-26943に関するアドバイザリエントリを発行しました

最後に、コミュニケーションのループを緊密かつ透過的に保ってくれたASUSチームに心から感謝します❤ 全体的なプロセスは速くはありませんでしたが、フラストレーションを感じることはありませんでした。