UEFI搭載コンピューターの大多数は、シムと呼ばれる小さな第一段階ローダーを信頼するMicrosoft証明書を保持しています。シムはLinuxやその他のブートツールがSecure Bootを有効にしたまま起動できるよう、Microsoftが署名を行うプログラムです。ところが、署名済みシムのうち11個は古すぎて、本来守るべき保護機能を無効化してしまうことが判明しました。ESETの研究者らがバージョン0.9以下の脆弱なシムを発見し、Microsoftは2026年6月9日のPatch Tuesdayアップデートでこれらを失効させました。
1つの証明書、多数のマシン
影響を受けるシムは、Microsoftのサードパーティ証明書「Microsoft Corporation UEFI CA 2011」を保持するあらゆるUEFIシステムから信頼され、OSの種類に関わらず同じように動作します。攻撃者はこれらの古いシムの1つを、対応する第二段階ローダーとともにターゲットマシンにコピーするだけで、ブートチェーンはそれを受け入れてしまいます。攻撃者自身がバイナリを用意するため、脆弱なソフトウェアを一度も出荷していないシステムにも攻撃が及びます。この問題には、CVE-2026-8863とCVE-2026-10797という2つの識別子が割り当てられています。
シムは署名に関する問題を解決する仕組みです。Microsoftが一度だけ検証・署名を行う最小限のローダーであり、その後は組み込まれたベンダー証明書を使って次の段階(通常はGRUB 2)を保証します。GRUB 2はさらに同じ証明書を使ってLinuxカーネルを検証します。
Linuxシステムにおける簡略化されたUEFIブートフロー(出典:ESET)
脆弱な第二段階
危険性は、これらの第二段階ローダーを通じてさらに拡大します。1つのシムが信頼するバイナリは、少ないもので10個未満、多い主要Linuxディストリビューションでは100個近くにのぼります。署名のタイムスタンプは2013年から2025年にまたがっており、古いものの多くには公に知られた不具合が存在します。中でもGRUB 2は最も脆弱なコンポーネントで、規模が大きく、バージョンが古くなるにつれ不具合が蓄積しています。
報告されたあるOracle Linux用シムは、Oracle Linux 7.1インストールメディアに含まれるGRUB 2バイナリを信頼していますが、これはCVE-2015-5281の影響を受けます。脆弱性情報によれば、この脆弱性は「UEFIシステムで使用された場合、細工された(1)multibootまたは(2)multiboot2モジュールを介して、ローカルユーザーが意図されたSecure Boot制限を回避し、未検証のコードを実行できてしまう」というものです。この攻撃はほとんど手間がかかりません。攻撃者は署名されていないmultiboot2カーネルイメージを作成し、古いシムとGRUB 2とともにEFIシステムパーティションにコピーして、起動時にコマンド1つでロードするだけです。
欠落している保護機能
古いシムには、シムプロジェクトが構築後に追加したセキュリティ機能も欠けています。失効したMachine Owner Key(MOK)をシステムが拒否できるようにするMOKデナイリストの適用は、バージョン0.9になって初めて導入されました。Secure Boot Advanced Targeting(SBAT)のサポートが加わったのはバージョン15.3です。これらの時点より前に構築されたシムは、対応する失効情報を無視してしまいます。攻撃者はパッチ適用済みのシムを、フィンランドの大学入学資格試験委員会(Matriculation Examination Board)の試験ソフトウェア由来のバージョン0.8シムのような、より古いMicrosoft署名済みシムに差し替えることが可能で、その場合、現行のポリシーで本来ブロックされているはずのバイナリが読み込まれてしまいます。
もう1つの欠陥は現在CVE-2026-10797として追跡されていますが、上流ではほぼ10年前に修正されていたにもかかわらず、この報告が出るまでCVE番号が割り当てられておらず、この欠陥を抱える古い署名済みシムは一度も失効させられていませんでした。署名済みPEバイナリは署名の長さを2箇所に記録しますが、影響を受けるシムは失効チェック時と署名検証時とで異なる箇所を参照してしまいます。第二段階ローダーのWIN_CERTIFICATE構造体を改ざんすることで、失効チェックを誤ったバイト位置に誘導でき、dbxやMokListXで失効したはずの証明書をすり抜けさせることができます。この回避手法が機能するのは、第二段階ローダーがシムに埋め込まれた証明書によって署名されている、証明書ベースの失効の場合のみです。ハッシュベースの失効については引き続き有効です。
修正の適用
証明書の有効期限切れは、この問題の解決にはなりません。MicrosoftのUEFI CA 2011証明書は2026年6月27日に失効しましたが、この日付自体はSecure Bootの検証に何ら影響しません。この証明書で署名されたブートローダーは、証明書がdbに残り、そのハッシュがdbxに含まれない限り、信頼され続けます。Microsoftはこの日付まで、この証明書を使って提出物への署名を行っていました。
これらのシムをブロックするには、現行のUEFI失効情報を適用することが基本になります。Windowsマシンはdbxアップデートを自動的に受け取り、ESETは昇格権限で実行することを想定した、失効済みの11個のハッシュが存在するかどうかを確認するPowerShellコマンドを公開しました。LinuxシステムはLinux Vendor Firmware Serviceを通じてアップデートを取得でき、uefi-dbx-auditスクリプトで結果を確認できます。Windows 11のSecured-core PCでは、サードパーティ署名はデフォルトで無効になっているはずです。
2017年に始まったshim-reviewリポジトリには、それ以降に署名申請されたすべてのシムが記録されていますが、それ以前に署名されたシムについては同様の記録が存在しません。そのため、現在も信頼され続けている古いシムがどれだけ残っているのか、確信を持って言える人は誰もいません。今回の11個のシムを失効させたことで、その母数は少なくなりますが、SBATのようなバージョンベースの失効の仕組みがあれば、次回のクリーンアップはより迅速に行えるようになります。同様の記録管理は、シム以外のサードパーティUEFIアプリケーションにも及ぶ必要があります。これらのアプリケーションも、独自のSecure Boot回避手法を生み出してきたからです。
翻訳元: https://www.helpnetsecurity.com/2026/07/14/eset-uefi-secure-boot-bypass/
