「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セキュリティナレッジベースの記事(英語)をご覧ください。

関連記事

Canonical、Kubernetes 1.19を発表

Canonicalは本日、パブリッククラウドからエッジまでをカバーするKubernetes 1.19のエンタープライズ向けフルサポートを発表しました。サポート対象にはCharmed Kubernetes、MicroK8s、kubeadmが含まれます。  Canonicalの製品マネージャーであるAlex Chalkiasは次のように述べています。「Canonicalは、ユーザーが最新の機能、ライフサイクル管理、アップストリームに合わせたエンタープライズサポートの恩恵を受けられるよう、すべてのリリースの迅速なフォローに努めています。Kubernetes 1.19では、MicroK8sおよびCharmed Kubernetesにおいても、強固なセキュリティ機能とキャリアグレー […]

実験的な機能:段階的リリース

「実戦で変更されない計画はない。」これはプロイセンの陸軍元帥ヘルムート・フォン・モルトケが残したとされる有名な言葉です。この言葉はソフトウェア開発にも当てはまります。「実用で変更されないコードはない」 ミッションクリティカルな環境で運用中のアプリケーションやサービスの安定性を最大限に確保するには、段階的にソフトウェアを展開し、更新を制御することが必須です。これにより開発者はツールの新しいバージョンの普及状況を監視および観察できるのに加え、運用チームはコンプライアンスとセキュリティの目標を満たすことができます。最近まで、Snapの自動更新のタイミングは主にクライアント側の更新スケジュールにより決定されてきました。このたび、Snap開発者が新しいリビジョンの展開を微調整するた […]


© 2020 Canonical Ltd. Ubuntu および Canonical は、Canonical Ltd の登録商標です。