ベンダー署名済み UEFI シェルが Secure Boot を素通り — BYOVD が起動前環境に降りた

Acer、AMD、ASUS、Gigabyte、Toshiba など主要 PC ベンダーが配布する ベンダー署名済み UEFI アプリケーション（多くは UEFI シェルや GRUB2）に、Secure Boot を実質的に無効化できる脆弱性があると CERT/CC が公表した（VU#457458 / JVNVU#93024090）。証明書チェーン自体は壊れていない。「正規に署名された道具」が攻撃者の踏み台にされるタイプの問題で、SignalRGB の件などで議論された BYOVD（Bring Your Own Vulnerable Driver）が、OS の手前 — プリブート環境にまで降りてきた格好だ。

攻撃の輪郭 #

UEFI シェルには本来デバッグ・修復用の強力なコマンド群が組み込まれている。mm（物理メモリの直接読み書き）、dmpstore / setvar（NVRAM 変数の参照と書き換え）、生のドライバロード機能。CERT/CC の説明では、攻撃者はこれら標準機能を使ってメモリ操作と NVRAM 書き換えを行い、Secure Boot の検証ロジックを通っていないコードをブート段階で実行させる。バイナリ自体は各ベンダーの正規証明書で署名済みのため、Secure Boot からは「これは信頼できるアプリです」としか見えない。

前提条件は 管理者権限または物理アクセス。「OS 侵害後の永続化」「盗難ノート PC からの解析」「修復メディアを偽装した内部攻撃」など、攻撃チェーンの最終段で価値が出るタイプの脆弱性だ。

なぜ厄介か #

通常のドライバ BYOVD は OS の保護機構（PatchGuard、HVCI、ELAM）と戦う必要があった。だが UEFI シェル経由なら、OS が起動する前にカーネル相当の領域を触れる。検出側にとっては「Windows が動き出した時点で既に汚染されている」状態で、エンドポイントセキュリティ製品が見える範囲の外側になる。Secure Boot は本来、こうした起動前の汚染を防ぐために導入された機構だが、その通行手形を発行されているアプリが何でもできるなら、関所の意味は失われる。

何をすべきか #

PKI で起動を縛れば安全、というのが Secure Boot の前提だったが、署名対象のアプリ自身が万能ツールだと PKI は無力化する。起動チェーンの信頼を「証明書の正しさ」ではなく「コードの能力」で測り直すべきだという、長らくの宿題を表面化させた事例といえる。