「There’s a hole in the boot(BootHole)」 – CVE-2020-10713の緩和と関連の脆弱性

by Canonical on 3 August 2020

責任ある開示と協調した対応が皆の利益に

Canonicalは本日、「There’s a hole in the boot(ブーツに穴がある)」、あるいはGRUB2(GRand Unified Bootloader version 2)のBootHoleと呼ばれる一連の脆弱性に関する最新情報を公開しました。この脆弱性により攻撃者はUEFIセキュアブートを回避できます。当初の脆弱性であるCVE-2020-10713は、優先度の高い脆弱性として2020年4月にCanonicalが警告を受けています。以来、Canonicalは7つの関連脆弱性を発見し、幅広いオープンソースコミュニティおよびMicrosoftと協力しています。そして本日、Ubuntuおよび主要Linuxディストリビューションに対応する緩和策の提供を開始しました。 

今回のブログ記事では、この脆弱性を解説するとともに、オープンソースエコシステム全体の協調によってどのように修正されたのか、その舞台裏をご紹介します。CVEの詳細情報および関連脆弱性を修正する更新パッケージについては、Ubuntuセキュリティナレッジベースの記事(英語)をご覧ください。 

この脆弱性の影響を理解していただくため、まずセキュアブートからGrubへのブートプロセスを説明します。UEFIセキュアブートは、ブートプロセス中に信頼できるコードだけを読み込むよう設計されています。したがって、これらの脆弱性により、攻撃者がマシンのブートプロセスを侵害し、不正な目的に悪用した可能性があります。GRUB2は、Ubuntuや他の多くのLinuxディストリビューションのインストール済みのシステムおよびインストールメディアで使用されているブートローダーです。また、これらの脆弱性はGRUB2にかなり前から存在していました。つまり、攻撃される可能性のあるLinuxリリースやインストール済みのインスタンスが多数あるということです。これほど広範囲に存在する脆弱性が注目を浴びるなか、システムとユーザーを保護するのは非常に困難です。たとえば、できるだけ多くの既存システムにパッチを適用すると同時に、既存システムの攻撃に使用されないよう古い脆弱なLinuxインストールメディアの使用を防ぐよう、スピーディーにセキュリティ更新を配信するにはどうしたら良いか。これには、Linuxディストリビューションのコミュニティ全体、さらにはMicrosoftなど幅広いUEFIコミュニティによる協調した対策が必要です。 

Canonicalのセキュリティチームは、2020年4月上旬、攻撃者がUEFIセキュアブートを回避できると思われるGRUB2の脆弱性について、Eclypsiumの研究者から最初の連絡を受けました。チームは、これがUbuntuにとどまらず幅広い影響を与えかねないことを認識し、アップストリームGRUB2のメンテナーに問題を報告するよう、即座に研究者に指示しました。2週間後、GRUB2のメンテナーがCanonicalおよび他のダウンストリームLinuxディストリビューションに連絡し、脆弱性を解決する協調的な取り組みに着手しました。脆弱性を特定するためにRed Hatによってただちに「CVE-2020-10713」が割り当てられ、脆弱性を修正する候補パッチが提案されました。次に、調整リリース日(CRD)、すなわち脆弱性の詳細を公表する合意済みの日時が設定されました。協議の結果、最終的なCRDは2020年7月29日協定世界時17:00に決定しました。この最終目標を設定した後、脆弱性の解決に具体的に何が必要かの詳細な調査が始まりました。

ソフトウェア更新をリリースしてインストールすれば脆弱性が修復される他のセキュリティ脆弱性と異なり、この問題が非常に複雑である原因はUEFIセキュアブートの本質にあります。 UEFIセキュアブートは、一般的にMicrosoftにアンカーされた信頼モデルを採用しています。PCがWindowsに準拠するには、Microsoft UEFI署名証明書をトラストアンカーとして採用する必要があります。つまり、Microsoftが信頼できると見なし、この証明書で署名したものであれば、UEFIセキュアブートでブートして良いということです。多くのLinuxディストリビューションでは、shimと呼ばれる小さなバイナリファイルがMicrosoftの署名を受け、GRUB2を読み込み、Linuxカーネルなどをブートするために使用されます。Linuxディストリビューションは、shimバイナリの中に独自の信頼証明書を組み込んでいます。これが、GRUB2がディストリビューションによって適切に署名され、UEFIセキュアブートの一環として信頼されていることを検証するために使用されます。前述のように、このshimとGRUB2バイナリは、UEFIセキュアブートが有効化されたときにブートされるよう、他のインストールメディアにも使用されています。このような古いインストールメディアは、たとえ脆弱なバージョンのGRUB2を含んでいても常に信頼されるため、どんなシステムでもUEFIセキュアブートの回避策として使用される可能性があります。幸運にもUEFI仕様では、UEFI禁止署名データベース(DBX)に追加すれば特定の証明書やバイナリの信頼を停止することが可能です。しかし、このデータベースに追加するにも、有効なトラストアンカー(つまりMicrosoft)がその追加分に署名する必要があります。したがって、各種のLinuxディストリビューションとMicrosoftが緊密に協調することで、将来的にシステムが古いインストールメディアから侵害を受けないよう、Microsoftが脆弱性およびブート禁止のGRUB2バイナリ/証明書の署名済みリストを提供する必要がありました。

Canonicalやその他の企業はMicrosoftと協力する過程において、GRUB2にすでに存在する可能性のある他の脆弱性も探しました。ある参加者の言葉を借りれば「2週間後にまた集まらないでもいいように」です。静的コードの分析と手作業での点検を通じて、Chris Coulson(Canonical)とColin Watson(Canonical兼DebianでのGRUB2メンテナー)は、多数の脆弱性を発見しました(CVE-2020-14308、CVE-2020-14309、CVE-2020-14310、CVE-2020-14311、CVE-2020-15706、CVE-2020-15707)。最後に、Mathieu Trudel-Lapierre(元Canonical)が発見した、既知のGRUB2の未解決脆弱性(CVE-2020-15705)も、今回の更新で修正されました。こうして合計8件の脆弱性について、Ubuntuの各種GRUB2リリースでパッチを適用し、既存システムでの問題を修正する必要があることがわかりました。

締めくくりは、パッチを適用したGRUB2ビルドおよびMicrosoftの署名済みDBX更新の準備とテストです。これにはChris CoulsonとDimitri John Ledkov(Canonical)が、CanonicalのOEMイネーブルメントチームのサポートを受けて力を尽くし、リグレッションなしに更新されることを確認しました。

舞台裏では、OEMのほか、Ubuntuを出荷するベンダー各社との緊密な協調や前述のようなディストリビューション間の調整がたくさんありました。こうした努力のおかげで、Ubuntuと他の主要Linuxディストリビューションは、CRDの時点で自社のユーザーも保護することができたのです。この取り組みは、Ubuntuという言葉の意味、つまり「皆があっての私(I am because we are)」を反映するものであり、Linuxおよび無料オープンソースソフトウェアの共有エコシステムの根本的な強さを実証しています。

脆弱性とそれを修正する更新パッケージに関する基本情報は、Ubuntuセキュリティナレッジベースの記事(英語)をご覧ください。

ニュースレターのサインアップ

Ubuntuニュースレターの配信登録

お客様が購読登録を行われる場合、以下の条件に同意されたことになります。Canonicalのプライバシーに関するお知らせ個人情報保護ポリシー

関連記事

Firefighting Supportを発表

新しいサービスでCanonicalの専門家が高度なクラウドサポートを提供 Canonicalのマネージドソリューションチームは、自社でインフラストラクチャの管理を行い、トラブルシューティングの必要があるときのみ専門家の対応を求める組織のために、新しいサービス「Firefighting Support」を発表しました。 Firefighting Supportでは、フルマネージドサービスを止めた、または厳しいセキュリティ規制によってサードパーティーに環境へのアクセスを許可できないお客様に対して、マネージドサービスレベルのサポートを提供します。このサービスはノードごとの年間料金で提供され、次のような内容です。 自己管理インフラストラクチャへの移行に理想的 現在の市場では、マネ […]

Linuxにセキュリティパッチを適用する頻度は?

セキュアな環境を維持するには定期的なパッチの適用が不可欠ですが、Linux環境を安全に保つための方法は環境によって異なります。運用の安定性を考えて、どのぐらいの更新頻度が妥当でしょうか? 最も制限が多く、規制が厳しい環境でも、準拠が保証され安全な方法で、セキュリティパッチの適用を自動化できる方針が存在します。セキュリティパッチの適用方針を定義するときは、Canonicalでのソフトウェア更新のリリーススケジュールを理解し、セキュリティパッチの適用の時間枠を知っておくことが不可欠です。私は最近、ライブのウェビナーとセキュリティの質疑応答を主催し、パッチ適用の回数を最小化するとともに、パッチが適用されていない脆弱性が悪用される回数も最小化する方法について解説しました。この記事 […]

CanonicalのCISOがEUサイバーレジリエンス法を完全解説

強力で対象の広い規制は、関係者の安全を確保する一方、不確定性をもたらす可能性があります。EUサイバーレジリエンス法(CRA)も例外ではありません。オープンソース関係者と技術業界全般にわたり、心配、不安、希望などさまざまな反応が見られます。 しかし怖がる理由があるのでしょうか? EUサイバーレジリエンス法が本当にオープンソースの状況を変えるのでしょうか? 企業はこの法律にどう備えれば良いのでしょうか? この記事ではEUサイバーレジリエンス法とその目的、要件、オープンソース関係者に対する影響を説明し、施行に備えたサイバーセキュリティ上のアドバイスをご紹介します。 EUサイバーレジリエンス法とは? EUサイバーレジリエンス法(CRA)とは、欧州連合(EU)の法律で、EUのIT業 […]