博士

ロボ子、大変なのじゃ！UEFI Secure BootをバイパスするCVE-2025-3052っていう脆弱性が見つかったらしいぞ！

ロボ子

Secure Bootのバイパスですか！？それはかなり深刻ですね。具体的にはどのような脆弱性なのでしょうか？

博士

Microsoftの第三者UEFI認証で署名されたモジュールに、メモリ破壊の脆弱性があるらしいのじゃ。攻撃者がこれを使って、署名されてないコードを実行してSecure Bootを突破するみたい。

ロボ子

署名されていないコードがブートプロセス中に実行されると、システムの信頼性が大きく損なわれますね。OSが起動する前にブートキットを仕込まれる可能性もあるのでしょうか？

博士

その通り！OSレベルのセキュリティ防御を無効化できるから、かなりヤバいのじゃ。原因はNVRAM変数の安全じゃない取り扱いにあるみたい。『`IhisiParamBuffer`変数の内容を検証せずにメモリ書き込み操作のポインタとして使用』している点が問題らしいぞ。

ロボ子

`IhisiParamBuffer`ですか。なんだか難しそうですね。でも、それが悪用されると、Microsoft Corporation UEFI CA 2011の証明書を信頼するデバイスに影響が出るのですね。

博士

そう！しかも、この証明書はLinuxブートローダーshimの署名にも使われてるから、影響範囲がめっちゃ広いのじゃ！

ロボ子

それは大変です！この脆弱性はどのようにして発見されたのでしょうか？

博士

VirusTotalで見つかったUEFIアプリケーションがきっかけらしいぞ。DT Research製のデバイス向けBIOSフラッシュツールだったみたいじゃ。Binarly Transparency PlatformがNVRAM変数の安全じゃない使用を検出して、CVE-2025-3052を特定したらしい。

ロボ子

Binarly Transparency Platform、すごいですね！既に対応は進んでいるのでしょうか？

博士

Binarlyは2月26日にCERT/CCに報告済みで、Microsoftは6月10日のPatch Tuesdayで14個の新しいハッシュをSecure Boot dbxに追加して対応したみたいじゃ。

ロボ子

迅速な対応で安心しました。Secure BootはUEFIによって構築された信頼チェーンにおいて重要な役割を果たしているんですよね。

博士

そう！ファームウェアからOSへの信頼を繋ぐ橋渡しみたいなものなのじゃ。OSローダーの整合性と信頼性を暗号的に検証して、悪意のあるコンポーネントによる置き換えを防ぐんだぞ。

ロボ子

今回の攻撃の流れは、まず攻撃者がOSから`IhisiParamBuffer`変数を設定し、署名されていないペイロードを含むモジュールを登録する、という感じでしょうか？

博士

その通り！再起動後、脆弱なモジュールが実行されて`gSecurity2`を上書きしてSecure Bootを無効化。その後、署名されてない2番目のモジュールがロードされて、攻撃者はDXEフェーズの最後に任意のコードを実行できるようになるみたいじゃ。

ロボ子

恐ろしいですね…。私たちエンジニアができる対策はありますか？

博士

影響を受けるユーザーは、dbxをできるだけ早く更新することを推奨するぞ！

ロボ子

承知いたしました。今回の件で、Binarly Transparency Platformが0-day脆弱性を自動的に検出したというのも素晴らしいですね。

博士

ほんとじゃ！署名された脆弱なモジュールをDB/DBXデータベース内でプロアクティブに検出できるのは、かなり心強いのじゃ。

ロボ子

今回の脆弱性から、セキュアブートの重要性と、常に最新のセキュリティ情報をキャッチアップすることの重要性を再認識しました。

博士

まったくだぞ！ところでロボ子、Secure Bootを突破する方法、こっそり教えてあげようか？…なーんて、冗談じゃ！そんなことしたら、お仕置きされちゃうのじゃ！