Microsoft Secure Boot、13年間脆弱なまま

Dan Goodin が Ars Technica で報じた記事に基づく。ESETの研究者らが、MicrosoftのSecure Bootを13年にわたって回避可能にする脆弱性を発見した。同機能が2009年に導入されて以来、実質的にその大半の期間において無力化されていたことになる。

“What makes these old shims dangerous is not a novel vulnerability,” ESET researcher Martin Smolár wrote Tuesday. “It’s that no new vulnerability is needed to bypass UEFI Secure Boot. An attacker needs no complicated exploitation primitives—only a copy of an old, still-trusted, but unrevoked shim binary and a basic understanding of how UEFI shims work. That is enough to bypass such an essential security feature as UEFI Secure Boot.”

問題の核心は「shim（シム）」と呼ばれるUEFIブートローダーにある。シムは元来、LinuxやユーティリティソフトウェアでもSecure Bootを利用できるようにするためにMicrosoftが署名管理を行う仕組みとして設計された。しかしESETは、少なくとも2013年製を含む11のシムバイナリが、脆弱性が判明した後もMicrosoftによって失効（revoke）されず、署名済みの状態で公開され続けていることを突き止めた。

攻撃者はこれらの古いシムファイルを入手し、それを用いてSecure Bootが要求するデジタル署名の連鎖（chain of trust）を乗っ取ることができる。この手法により、マルウェアをブートプロセスの初期段階に組み込み、OSの再インストールやHDD交換後も持続させるブートキットの設置が可能になる。Smolár氏が指摘する通り、新たな脆弱性や高度なエクスプロイト技術は不要であり、初級レベルのハッカーでも実行可能な単純な手順で回避が成立する。

11の失効漏れと影響範囲

CERTがまとめたリストによれば、失効されていない11のシムのうち、一部はRed Hat、openSUSE、OracleといったLinuxディストリビュータによって使用されていた。また、PC-Doctor FinlandのMatriculation Examination Boardなど、サードパーティ製ソフトウェアに含まれていたものもある。これらのシムの多くは、SBAT（Secure Boot Advanced Targeting）やMOK（Machine Owner Key）拒否リストといった保護機構が存在する以前にビルドされたものだ。さらに、コード自体や、シムが認証する第2段階バイナリに累積的なバグを含むものも存在する。

この脆弱性はWindowsユーザーとLinuxユーザーの両方に及ぶ。シムは両OS上でインストール可能であり、いったんブートプロセスに割り込めばOSの種別を問わず影響が生じる。マルウェアはドライブ交換後も存続するため、システムクリーンインストールによる駆除が困難となる。

Secure Bootの回避は、ブートキット（bootkit）攻撃への扉を開く。Bootkitとは悪質なファームウェアの総称であり、過去にはロシア国家ハッカーが2018年に使用したLoJax、2020年のMosaicRegressor、2022年のCosmicStrand、2023年のBlackLotusといった実例が確認されている。ESETはこの他にもESpecter、FinSpy、MoonBounceなど複数のブートキットを追跡している。

脅威モデルと攻撃シナリオ

Secure Bootは2012年に導入され、PCの起動プロセス全体で署名済みコードのみを実行することでブートキットの脅威を軽減する設計だ。攻撃者がデバイスに物理的アクセスを得た場合、電源オフ状態でもブートキットのインストールが可能となる。Secure Bootはまさにこうした脅威モデルを防御対象として明示している。

今回の脆弱性は、攻撃者が物理的アクセスを得た場合のリスクを特に高める。ただし、すべてのブートキットが物理アクセスを必要とするわけではない。リモートからブートプロセスに介入できる手法も存在するため、脅威の範囲はさらに広がる可能性がある。

Microsoftはシムの署名管理を担当する立場にありながら、既知の脆弱性を持つシムを失効させる責務を怠った。このガバナンスの欠如が、13年にわたるセキュリティホールを生んだ直接の原因である。

編集部の見解

短期的には、この脆弱性の存在が広く認知されることで、Microsoftは速やかに全11のシムを失効リストに追加する対応を迫られる。同時に、影響を受けるLinuxディストリビュータやサードパーティベンダーは、SBATやMOK拒否リストのアップデートを通じて自社製品の防御を強化する必要がある。企業のセキュリティチームは、自社の資産に脆弱なシムがインストールされていないか確認する監査を急ぐべきだ。特に物理的な端末管理が難しいリモートワーク環境では、この脆弱性の悪用リスクが無視できない。 長期的には、本件はソフトウェアサプライチェーン管理の根本的な問題を浮き彫りにしたと言える。署名権限を持つプラットフォームベンダーが、過去に署名したバイナリをどの程度の期間・頻度で監査し、失効すべきかを判断するプロセスが問われている。また、Secure Bootという仕組み自体が「信頼の連鎖」に依存している以上、その連鎖を維持するための継続的な運用コストが不可避である。この問題はMicrosoftに限らず、GoogleやAppleなど他のプラットフォームベンダーにも共通する課題だ。

参考

• 「Microsoft’s Secure Boot has been broken for a decade and no one noticed until now」, by Dan Goodin — Ars Technica, 2026-07-14T22:20:48.000Z (CC BY-NC-ND)
• 元記事URL: https://arstechnica.com/security/2026/07/microsoft-secure-boot-has-been-broken-for-most-of-its-existence/