baton drop (CVE-2022-21894): セキュアブートのセキュリティ機能バイパスの脆弱性

Windows ブートアプリケーションは、truncatememory 設定を使用して、メモリマップからシリアライズされたデータの「永続的」な範囲を含むメモリブロックを削除することを許可し、セキュアブートのバイパスにつながります。

• truncatememory BCD要素は、指定された物理アドレスより上のすべてのメモリをメモリマップから削除します。
• これは各ブートアプリケーションの初期化中に、シリアライズされたセキュアブートポリシーがメモリから読み込まれる前に実行されます。
• したがって、このような要素を使用して、メモリマップからシリアライズされたセキュアブートポリシーを削除できます。
• これにより、ブートアプリケーションで危険な設定（bootdebug、testsigning、nointegritychecks）が使用可能になり、セキュアブートが破られます。

この問題は2つの異なる変更で修正されました：

• シリアライズされたセキュアブートポリシーの読み込みを試みた後、ポリシーが読み込まれず、セキュアブートが有効で、ブートアプリケーションがUEFIファームウェアによって直接ロードされておらず、ブートアプリケーションがbootmgrでない場合、ブートアプリケーションの初期化は失敗します。
• ブートアプリケーションをロードするとき、VERSIONINFOリソースにOriginalFilenameが含まれている場合、そのファイル名がブロックリスト（bootmgr.exeとhvloader.exeを含む；Nickelではhvloader.efiが追加されたが、バックポートされなかった）に含まれていると、ロードは失敗します。
  • Windows 8およびWindows 8.1では、hvloader.exeはwinloadのブロックリストに含まれていません - 元々含まれていたため、Hyper-Vのロードが壊れていました！
  • Windows 10バージョン1809以降、特定のフラグビットが設定されている場合（flightedbootmgr要素と共に使用され、ディスクからbootmgrをロードする）、OriginalFilenameは必須でbootmgr.exeである必要があります。

悪用

攻撃者は、シリアライズされたセキュアブートポリシーが既知の物理アドレスより上に割り当てられるようにする必要があります。

• デフォルトでは、可能な限り低いアドレスに割り当てられます。
• 元々、シリアライズされたセキュアブートポリシーはロード後に、BCDからロードされた構成を使用する前に割り当てられていました。
  • RS1以降、シリアライズされたセキュアブートポリシーはブートアプリケーションのロード時に割り当てられます。
  • RS2以降、既存のシリアライズされたセキュアブートポリシーは、セキュアブートポリシーのシリアライズ時に解放されます。
• シリアライズされたセキュアブートポリシーは、ブートアプリケーションのロード時に、BCDエントリのosdeviceがBitLockerで暗号化されたパーティションであり、VMKがTPMを使用して導出された場合、再割り当てされます。
  • これは、TPMのアンシールが成功した後、キーフラグのビット0を設定することで偽装できます。このビットはBitLockerメタデータ内で手動で設定でき、整合性検証にセキュアブートが使用されていることを指定する追加のメタデータを追加できます。

avoidlowmemory要素を使用すると、物理メモリのすべての割り当てが指定された物理アドレスより上にあることを保証できます：

• Windows 10以降、VBSが有効な場合、この要素は許可されませんが、ブートアプリケーションの初期化中、シリアライズされたセキュアブートポリシーがメモリから読み込まれる前に使用されるため、bootmgrをロードし、カスタムBCDパス（bcdfilepath要素、別名custom:22000023を使用）を指定することで、これをバイパスできます。
• OSボリュームにBitLockerが存在する場合、またはターゲットシステムがTH1またはTH2を実行している場合、この方法は失敗します。そのため、Windows 8.xのbootmgrを使用して一度攻撃を実行し、VBSを無効にしてから元のブートローダーに戻すことも可能です。
  • Windows 10はブートアプリケーションの初期化を変更し、すべてのTPM PCRを一度だけキャップするようにしたため、Windows 8.xのbootmgrはWindows 10以降のシステムでVMKのアンシールに失敗します。

hvloader.efiはnointegritychecks要素を使用してロードでき、自己署名されたmcupdate.dllをロードします。そのエントリポイントはExitBootServicesの前に呼び出されます。

あるいは、非AMD64システムでは、TH2より前のwinload.efiをtestsigning要素と共に使用できます。これにより、証明書にszOID_NT5_CRYPTO EKUを持つ自己署名バイナリが許可されます。

ARMv7システムでは、mcupdate.dllへのインポートを含むパッチ済みの自己署名hal.dllをロードしてコード実行を得る必要があります。

x86およびAMD64システムでは、mcupdate.dllとしてロードされるファイルはmcupdate_*.dllという名前でなければなりません。ここで*はCPUIDの製造元文字列（GenuineIntel、AuthenticAMDなど）です。

ARM64システムでは、利用可能な最も初期のプロダクション署名済みビルドがRS2のWinPEであるため、このテクニックは使用できません。したがって、現在は（bootdebugを使用した）テザリングされたコード実行のみが可能です。

含まれるファイル

このリポジトリには以下のファイルが含まれています：

• シンプルなペイロードのソースコードが提供されています。このペイロードは、呼び出し元のブートアプリケーション内の興味深い関数や変数を見つけられなければ他に何もできないため、無限に割り込みを待つだけです。
  • mcupdate.dllはページングが有効な仮想アドレスで実行されるため、EFI関数を直接呼び出すことはできません（EFI関数を呼び出すにはページングを無効にする必要があり、ページングがオフの状態で仮想アドレスに戻っても良い結果にはなりません）。
    • EFI関数を呼び出すには、ペイロードは、フラグのビット0を設定してBlImgLoadPEImageExまたはBlImgLoadPEImageFromSourceBufferを呼び出し、追加のペイロードを物理アドレスと仮想アドレスが1:1でマッピングされた場所にロードする必要があります。
      • または、同じビットを設定してBlImgAllocateImageBufferを呼び出し、物理アドレスと仮想アドレスが1:1でマッピングされたメモリを割り当て、その後自分でペイロードをロードする（または自分自身をそこに再マッピングする）こともできます。
• Windows 8 RTMのbootmgfwとTH1 RTMのhvloaderを使用してAMD64でこの問題を悪用するISO。
  • ここで使用されるペイロードは、オフセットで取得したhvloaderの関数を使用して画面にメッセージを表示し、その後無限ループします。
• RS1のbootmgrとTH1 RTMのhvloaderを使用してAMD64でこの問題を悪用するISO。
• バージョン19041.1081のbootmgrとTH1 RTMのhvloaderを使用してAMD64でこの問題を悪用するISO。

追記

この問題は、BitLockerキー（セキュアブートが整合性検証に使用されている場合）をダンプするために使用できます。

• 可能性はありますが、メモリ内の任意のボリュームから導出されたBitLockerキーを使用してコード実行を得る正確な方法は開示されません。

この問題に対する修正は、CVEを持たない別の問題も修正しました。

• bootmgrはメモリ内に既存のBitLockerキーテーブルを無視し、新しいものを割り当てますが、古いものを消去しません。
  • したがって、攻撃者はbootmgrからRS2+のbootmgrをロードし（セキュアブートが整合性検証に使用される任意のosdeviceを指定）、WinPEにブートし、既知の脆弱なドライバをロードし、それを使用して物理メモリ内の既存のBitLockerキーテーブルを検索およびダンプできます。

既知の脆弱なブートアプリケーションはまだ失効されていません。

• 失効が行われるまで、攻撃者は自分自身の脆弱なブートローダーを持ち込むことができます。
• 失効は、既存のすべてのWindowsインストール/回復メディア、および古いバックアップをブートできなくします。
  • ブート失敗は、セキュアブートが無効な場合でも、bootmgrが自身の署名をチェックするために発生します。

更新 (2023-05-10)

不完全な失効が発生し、別のCVE（CVE-2023-24932）が発行されました。依然として失効されていない脆弱なbootmgfwが存在し、さらに追加のパッチはbootmgrがbootmgrをロードするケースのみを修正しています。MSが動くには、貼り付けられたブートキットが必要だっただけです ;)
もしあなたが十分に創造的であれば、2000以上のbootmgfwファイルの失効を回避する方法を見つけるでしょう ;)