GIGABYTE H510M K V2 BIOS SMM リバースエンジニアリング & CVE-2025-7026/7027/7028/7029 リサーチ

GIGABYTE H510M K V2(H510MKV2.F3)BIOSイメージの静的リバースエンジニアリング: PI仕様のSMM Coreメモリアロケータの完全なUEFIファームウェアボリューム抽出分析、およびGIGABYTE/Binarlyが2025年に開示した4件のSMMメモリ破壊の脆弱性(CVE-2025-7026 CVE-2025-7027 CVE-2025-7028 CVE-2025-7029)を対象とした的を絞った探索。

ステータス: 4件中1件のCVE(CVE-2025-7027)が存在することを確認。残り3件はアクセス可能な全ファームウェアにわたって積極的に検索したが発見されず、それが何を意味し何を意味しないかの正確な内容は未確認のCVEを参照。

リサーチの全ファイル: GOOGLE DRIVE ダウンロード: SMM_ALL

目次

• 免責事項 / スコープ
• 対象
• TL;DR
• 手法とツール
• ファームウェア構成
• リポジトリ構成
• 背景: 公開済みCVE
• ボーナス発見: SMMメモリアロケータ (PiSmmCore)
• 確認済み: CVE-2025-7027
• 未確認のCVE: CVE-2025-7026 / 7028 / 7029
• 対策
• 制限事項
• 参考文献

免責事項 / スコープ

これはn-dayリサーチであり、0-day開示ではありません。ここで参照する4件のCVEはすべて、このリサーチが始まる前に、GIGABYTEによってすでに公開開示・パッチ適用済み(パッチ済みファームウェアは2025-06-12に出荷開始)であり、BinarlyとCERT/CCによってCVEが割り当てられ文書化されていました。このリポジトリの内容は新しい脆弱性の発見ではありません。これは、特定の公開ダウンロード可能なBIOSビルドに、以前に開示・パッチ適用済みのバグクラスが存在するかどうかを検証する独立した静的解析です。

• 実働するエクスプロイトやPoCは含まれておらず、作成もされていません。 これは静的解析のみです(抽出したファームウェアモジュールの逆アセンブル/逆コンパイル)。何も実行されておらず、SMRAMの読み書きもなく、ハードウェアにも触れていません。
• 新しい脆弱性は主張されていません。 CVE-2025-7027の存在は、Binarlyがすでに公に説明している脆弱なコードパターンとの一致によって確認されたものであり、独自に発見したものではありません。
• 教育/防御的セキュリティ目的で公開: n-dayファームウェアバグが実際にどのように見えるかを理解すること、そしてこの特定のボード/BIOSリビジョンに対するGIGABYTE自身のアップデート推奨を具体的な証拠で裏付けること。
• このボードをお持ちの場合は: BIOSを更新してください。 対策を参照。

対象

TL;DR

• BIOSイメージから完全なUEFIファームウェアボリュームツリーを抽出(uefi_firmware / uefi-firmware-parser)。SMM/DXEボリューム全体で356個のFFSファイルを列挙し、そのうち302個に抽出可能なPE32/TEイメージが含まれていました。
• PiSmmCore(PI仕様のSMM Core)を分離し完全にリバースエンジニアリング。ハードコードされた"sphd"/"tail"ガードシグネチャを介して、実際のSMMプール/ページアロケータ(SmmAllocatePool/SmmFreePool/SmmAllocatePages/SmmFreePages内部)を確認・命名しました。これはEDK2のオープンソースMdeModulePkg/Core/PiSmmCore/Pool.cと完全に一致します。
• ROM内で見つかったすべてのファームウェアボリューム内のすべての抽出可能なモジュール(合計325以上)を、Binarlyの公開CVE-2025-7026/7027/7028/7029解説書の識別マーカーについて検索しました。
• CVE-2025-7027 確認済み。 GenericComponentSmmEntry内の正確な脆弱コードパスを発見・追跡しました。NVRAM変数(SetupXtuBufferAddress)がGetVariable()を介して検証なしで取得され、SW SMI 経由で到達可能な書き込みポインタとして直接使用されています。これはBinarlyの公開された根本原因の説明と細部に至るまで一致します。

手法とツール

1. 抽出 uefi_firmware (uefi-firmware-parser -e) がBIOSイメージを再帰的に展開: Intel Flash Descriptor領域 → ファームウェアボリューム → FFSファイル → セクション。見つかったすべてのLZMA/Tiano圧縮ファームウェアボリュームを解凍しました。
2. モジュール分離 .ui(ドライバ表示名)セクションと.pe/.teイメージセクションを持つすべてのFFSファイルを、<DriverName>__<GUID8>.<pe32|te>という名前のスタンドアロンPE32+/TEバイナリとしてコピーしました。
3. 静的解析 Hex-Rays逆コンパイラを備えたIDA Pro(ida-pro-mcp / idalibヘッドレスワーカーインターフェース経由)。モジュールごとに1つのデータベース。自動解析 + Hex-Raysのみ。この環境ではFLIRTシグネチャやEDK2型ライブラリは利用できませんでした(後述の制限事項に記載)。
4. マーカー検索 Binarlyの公開アドバイザリに記載された識別子(変数名、マジック定数、関数ラベル)について、抽出したすべてのモジュール(および生の16 MBイメージ)をPythonでバイト/文字列スキャンしました。
5. 手動トレース マーカーがヒットするたびに、参照している関数を逆コンパイルし、そのコールグラフ(呼び出し元/呼び出し先)を手動で辿って実際のコードパスを再構築し、公開された根本原因の説明と照合しました。
6. 名前変更 確認された関数はIDAデータベース内で名前を変更し、文章だけでなく解析可能な成果物に直接発見を記録しました。

ファームウェア構成

BIOSイメージには4つのIntel Flash Descriptor領域が含まれています。GIGABYTE/OEMコードを含むのはregion-biosのみです(region-me.fd region-gbe.fd region-pdr.fdはIntel Management Engine / GbE / ディスクリプタファームウェアであり、別コンポーネントのためスコープ外として調査していません)。

region-bios内で4つのファームウェアボリュームが見つかり抽出されました:

4つすべてを抽出しマーカースキャンしました(未確認のCVEを参照)。

リポジトリ構成

SMM/
├── README.md                    this file
├── CVE_ANALYSIS.md              full technical deep-dive (code-level detail confidence notes)
├── flash.fd                     copy of the extracted 16MB BIOS image
├── regions/                     raw recursive extraction (every FV/FFS/section as produced by uefi_firmware)
├── smm_modules/                 PiSmmCore isolated + fully analyzed (.pe32 + Hex-Rays .i64 renames applied)
├── smm_modules_all/             all 51 `Smm*`-named drivers as standalone PE32/TE + manifest.txt
│                                 (4 extra ones  PiSmmCpuDxeSmm SmmAccess SmmControl SmmLockBox
│                                  FlashSmiSmm FlashDriverSmm  have auto-analyzed .i64 databases)
├── all_modules/                 every extractable module from the main DXE/SMM volume (302 not just Smm*-named)
├── extra_volumes_modules/       modules from the two smaller auxiliary firmware volumes
└── f641_pei_modules/            modules from the duplicate PEI-phase volume copy

背景: 公開済みCVE

4件すべてに共通する点: Software SMIハンドラが、レジスタまたはNVRAM由来の値を、実際にSMRAMの外にあるかを検証せずにメモリへのポインタとして信頼しています。これによりring-0(Administrator/root)の攻撃者が、通常のSW SMIトリガーをSMM特権(ring -2)の任意読み取り/書き込みに変換し、ファームウェア全体の侵害、Secure Bootのバイパス、OSより下の層への永続化を実現できます。

ボーナス発見: SMMメモリアロケータ (PiSmmCore)

これは脆弱性ではありません。セキュリティバグに向けられる前に、ツールチェーン(抽出 → PE分離 → IDA/Hex-Rays → 手動RE)が実際にソースで検証可能な本物のEDK2内部構造を復元できることを証明することで、残りの作業の基盤となった背景調査です。

PiSmmCore(GUID e94f54cd-81eb-47ed-aec3-856f5dc157a9)はPI仕様のSMM Coreです。SmmAllocatePool/SmmFreePool/SmmAllocatePages/SmmFreePagesとSMIハンドラディスパッチテーブルを保持しています。

コールチェーン(smm_modules/PiSmmCore.pe32.i64内のアドレス):

_ModuleEntryPoint (0x1184)
  -> SmmCoreEntryPointHelper (0x14D4)        writes the "SMST" table signature
     -> SmmInternalAllocatePool_wrapper (0x95EC)
        -> InternalAllocPoolByIndex_sphd_tail (0x57A8)     <- the allocator
     -> SmmAllocateZeroedPool (0x961C)        alloc + zero wrapper

SmmFreePool_wrapper (0x9714)
  -> SmmIsBufferInsideSmram (0x95A8)          decides SMRAM-resident vs not
  -> SmmInternalFreePool_sphd_tail (0x591C)   validates sphd/tail frees
     -> InternalFreePages (0x6A2C)            page-granularity free + coalesce
InternalFindFreePages (0x6820)                page-granularity alloc (mirror of InternalFreePages)

InternalAllocPoolByIndex_sphd_tail(0x57A8)は、本物のEDK2 MdeModulePkg/Core/PiSmmCore/Pool.cアロケータであることが確認されました。リテラルASCIIシグネチャ"sphd"(SMM_POOL_HEAD_SIGNATURE)と"tail"(SMM_POOL_TAIL_SIGNATURE)をハードコードしており、これはオープンソース実装の正確なマジック定数です。0x800バイト以下の要求はサイズクラスのフリーリストサブアロケータを経由し、より大きな要求はページフリーリストを辿り、返されたチャンクをヘッド/テールガードシグネチャで包みます。解放側の対応物(SmmInternalFreePool_sphd_tail)は、メモリをフリーリストに戻す前に同じシグネチャを検証します。

すべての名前変更はsmm_modules/PiSmmCore.pe32.i64に組み込まれています。Hex-Raysを備えたIDAで開いて直接確認できます。

確認済み: CVE-2025-7027

モジュール: GenericComponentSmmEntry (GUID 9caa3071-3459-4c5b-bbf0-ee68fe4dd46d) ファイル: smm_modules_all/GenericComponentSmmEntry__9caa3071.pe32 (+ 解析済み.i64)

発見方法

抽出したすべてのモジュール(51個のSmm*命名ドライバ、次にメインボリュームの全302個、そして補助ボリューム)を、BinarlyのCVE-2025-7027解説書が引用する正確なNVRAM変数名SetupXtuBufferAddressについてバイト/文字列スキャンしました。GenericComponentSmmEntry内(および、おそらくそれを設定/公開するDXE側のGenericComponentDxeEntry内)でUTF-16LE文字列として一致しました。

脆弱なチェーン

1. GetXtuBufferAddress_FromNvram (0x1F270) は gRT->GetVariable(L"SetupXtuBufferAddress" &Guid NULL &Size=8 &OutBuffer) を呼び出します(ランタイムサービス形式テーブルのオフセット+72 = GetVariable)。このNVRAM変数に保存された生の8バイト値を返します。その値が実際に何であるかの検証は一切ありません。

2. SUSPECTED_CVE_2025_7027_UnvalidatedXtuPtrWrite (0x18400) は上記を呼び出してv3(NVRAM由来の「アドレス」)を取得し、その後(自身の入力構造体a1[3]から取得したカウントで上限が決まる)ループで以下を実行します:

*(WORD *)(v3 + 2 * v7 + 12) = v9;   // v3 = raw NVRAM value v9 = attacker-influenced data

v3は書き込みターゲットとして使用される前に、実際の範囲内かつSMRAM外のアドレスであることが決してチェックされません。SetupXtuBufferAddressは(このビルドではSMMロックされていない)通常のNVRAM変数であり、ring-0攻撃者はSMIをトリガーする前にSetVariable()で任意のアドレス(例: SMRAMアドレス、または重要なカーネル/ハイパーバイザー構造体)に設定でき、制御されたSMM特権のwrite-what-whereを引き起こせます。

3. ComponentDispatch_KeymapOrXtu (0x18590) はディスパッチコールバックです。内部コンポーネントデータベースからコンポーネントタイプのバイトを取得し、type == 1の場合は上記の脆弱な関数を呼び出します。タイプ0はSetupVar_SafeKeymapWrite_bounded(0x18234)に進みますが、こちらは対照的に、実際のSetup NVRAM変数に対して適切なサイズ対容量の境界チェックを行います。この対照こそが、XTUパスを異常な未チェック経路として際立たせています。

4. sub_18698 はComponentDispatch_KeymapOrXtuをディスパッチ値**0xB2(10進数178)**に対して登録します。これはBinarlyのアドバイザリがこのバグクラスについて挙げている正確なSwSmiInputValue 0xB2です。これにより、ソフトウェアSMIトリガーポートが脆弱なディスパッチパスに直接結び付けられます。

確信度: 高

• NVRAM変数名の完全一致(SetupXtuBufferAddress)。逐語的に一致。
• SW SMIトリガー値の完全一致(0xB2)。
• コードパターン(信頼できないポインタを取得し、メンバーシップ/境界チェックなしで書き込む)が「二重ポインタ参照 … 任意のSMRAM書き込み」という根本原因と正確に一致。
• 独立には未確認: 最後のホップ、つまりSMIエントリ時のRBXレジスタがComponentDispatch_KeymapOrXtu/a1[3]に到達するコンポーネント選択入力にどう供給されるかは、生のCPUセーブステート読み取りまで完全には追跡できませんでした。そのためには、GenericComponentSmmEntryの登録済みコールバックを呼び出す前に、登録済み0xB2値でディスパッチする処理をもう一巡追跡する必要があります。

これは、CVEに記載された脆弱なパターンがこのBIOSビルドに存在するという静的解析による確認であり、実働するエクスプロイトやPoCではありません。SMRAMの内容、セーブステートのレイアウト、実行時の動作は一切検証されていません。

未確認のCVE: CVE-2025-7026 / 7028 / 7029

検索対象

Binarlyのこれら3件のCVEに関する公開解説書に記載されているすべてのマーカー($DB$ 2DB$ SwSmi OcHeader FuncBlock CommandRcx0 ReadFlash WriteFlash EraseFlash GetFlashInfo)を、リテラルバイトシーケンスとして、および(該当する場合)UTF-16LE文字列として、以下に対して検索しました:

• 生の16 MB flash.fdイメージ。
• メインDXE/SMMボリューム内の抽出可能な全302モジュール(all_modules/)。
• 2つの補助ファームウェアボリューム内の全モジュール(extra_volumes_modules/)。
• 複製PEIフェーズボリュームコピー内の全22モジュール(f641_pei_modules/)。

これらのマーカーはどこにも見つかりませんでした。 一致したのはSetupXtuBufferAddress(CVE-2025-7027)と、一般的なOverClock UIテキスト文字列(無関係なBIOSセットアップメニューのラベル)のみです。

なぜ「問題なし」ではなく結論不確定なのか

SetupXtuBufferAddressは、GetVariable()に渡される実際のNVRAM変数名であるため、リテラル文字列として現れる必要がありました。この文字列は機能的に必須です。対照的にCommandRcx0 OcHeader FuncBlockは、Binarlyがリバースエンジニアリングした匿名/ストリップ済み関数に対するBinarly自身の内部ラベルのように読め、バイナリに埋め込まれた識別子ではありません。文字列として存在しないことは、基盤となるコードが存在するかどうかについて何も証明しません。$DB$/2DB$マジック定数は、存在すればバイトレベルの一致として現れるはずですが(コンパイルされた比較文字列の即値オペランドとして現れるかどうか)、存在しないことはやや意味があるものの、やはり決定的ではありません(異なる即値エンコーディング、モデル別のファームウェアバリアント、または若干異なるチェック順序はすべて、生の部分文字列スキャンをすり抜ける可能性があります)。

このリサーチを続ける場合の具体的な次のステップ

1. CVE-2025-7028(フラッシュ操作)。 FlashSmiSmm(GUID 6c289241-...)とFlashDriverSmm(GUID 0c375a90-...)が最有力候補です。名前がReadFlash/WriteFlash/EraseFlash/GetFlashInfoとほぼ完全に一致します。両方とも抽出・自動解析済み(smm_modules_all/内の.i64データベースでHex-Rays対応)ですが、手動トレースは未実施です。それぞれ174関数と243関数で、区別可能な静的マーカーがなく、CVE-2025-7027で実施したのと同じ種類の手動ディスパッチャートレースが必要です(SW SMI 0xB2相当の登録を見つけ、関数ポインタテーブルのディスパッチまで追跡し、テーブルポインタが検証されているかを確認する)。
2. CVE-2025-7029(電源/熱 OcHeader)。 有力候補: GenericComponentSmmEntry自体(このまさにそのモジュールで未チェックポインタバグの発生源であることが実証済み)、、、、。いずれもまだ手動トレースされていません。

これらは今回のパスでは完了していません。ギャップが「チェック済み・問題なし」と暗黙に示されるのではなく、明確に見えるようここに明示的にフラグ付けしています。

対策

このボード(またはこのアドバイザリの対象となる240以上のGIGABYTEモデル)をお持ちの場合: GIGABYTEのサポートサイトから最新のBIOSに更新してください。 GIGABYTEは2025-06-12にパッチ済みファームウェアの出荷を開始しました。ここで解析したビルド(H510MKV2.F3、2023-12-20付)はそれより約18か月前であり、未パッチであることと整合します。これは理論上の推奨ではありません。このリサーチは、CVE-2025-7027の実際の脆弱コードパスがこの特定のビルドに存在することを発見しました。

制限事項

• この解析環境ではEDK2/UEFI型ライブラリ(.til)を利用できなかったため、SMMシステムテーブル(gSmst)/プライベートデータ構造体のフィールドをHex-Raysで自動マッピングできませんでした。解析における一部の構造体オフセットの解釈は、適用された型情報ではなく手動トレースに基づいています。
• 静的解析のみ。動的テスト、エミュレーション、ハードウェアアクセスはありません。調査結果はコードの到達可能性と形状を説明するものであり、実ハードウェア上での実行時悪用可能性を確認したものではありません。
• region-me.fd region-gbe.fd region-pdr.fd(Intel ME / GbE / ディスクリプタ領域)は調査していません。スコープ外です(GIGABYTE/OEMのSMMコードではなく、別のファームウェアコンポーネント)。
• 4件中3件のCVEは上記の詳細のとおり未確認のままです。

参考文献

• GIGABYTE Security Advisory 2302
• CERT/CC VU#746790
• Binarly BRLY-DVA-2025-008 (CVE-2025-7026)
• Binarly BRLY-DVA-2025-011 (CVE-2025-7029)
• NVD: CVE-2025-7026
• uefi_firmware / uefi-firmware-parser
• このREADMEが要約する完全なコードレベルの技術的詳細についてはCVE_ANALYSIS.mdを参照してください。