ブートホールの脆弱性 - GRUB 2 ブートローダー - CVE-2020-10713

エグゼクティブサマリー

Red Hat は、現在 Red Hat Enterprise Linux を含む Red Hat 製品に影響を与える GRUB 2 ブートローダーの不具合に対応中です。この不具合により、システム上にすでに存在する攻撃者は、ブートプロセスを乗っ取り、システムの起動時に悪意のあるコードを実行することが可能になります。UEFI Secure Boot は、コンピューターの起動に使用されるソフトウェアを検証してシステムを保護する機能ですが、この脆弱性を悪用すると、UEFI Secure Boot を使用しているシステムを回避することも可能になります。この問題には CVE-2020-10713 が割り当てられ、セキュリティー上の影響度は「中程度の影響」と評価されました。影響を受けるバージョンをお使いのお客様は、更新を適用することが推奨されます。さらに、コンテナーホストシステムの最新イメージと最新バージョンに更新することが推奨されます。

以下のバージョンの Red Hat 製品が影響を受けます。

• Red Hat Enterprise Linux 7

• Red Hat Enterprise Linux 8

• Red Hat Atomic Host 

• OpenShift Container Platform 4 (RHEL CoreOS)

現在ご使用のシステムにこの不具合による脆弱性が存在するかどうかを判断するには、以下の「診断」セクションを参照してください。さらに、以下に提供される自動修正の Ansible Playbook を参照することもできます。

テクニカルサマリー

CVE-2020-10713 では、攻撃者は GRUB 2 の不具合を悪用して GRUB の検証プロセスを乗っ取り、改ざんする可能性があります。さらに、Security Boot の保護機能を回避することが可能になります。攻撃者は、信頼できないカーネルや変更が加えられたカーネルをロードするために、最初にシステムへのアクセスを確立する必要があります。これには、物理的なアクセスの確保、pxe-boot ネットワークを変更する手段、root 権限によるネットワークシステムへのリモートアクセスなどが必要です。アクセスを確立することにより、攻撃者は GRUB 内部で任意コードを実行するための悪意のあるペイロードを挿入することで、バッファーのオーバーフローを発生する文字列の作成が可能になります。 

ロードしたカーネルの Secure Boot 保護が確実に機能するようにし、起動時にシステムが信頼できないコードをロードしないようにするため、grub2、kernel、fwupdate、fwupd、shim、および dbxtool パッケージに対して新たに検証された鍵と証明書が発行されました。

軽減策

この不具合の軽減策はありません。 

修復

Red Hat は、すべてのお客様に grub2 パッケージの更新を推奨しています。Secure Boot をご使用のお客様は、新たに検証された鍵および証明書が含まれる kernel、fwupdate、fwupd、shim、および dbxtool パッケージを更新する必要があります。

Red Hat Enterprise Linux 8 で Secure Boot を実行しているユーザーは、grub2 パッケージの更新を適用した後に、これまでにリリースされた RHEL 8 カーネルでブートするための追加手順を実行する必要があります。詳細は以下の RHEL 8 のセクションを参照してください。

技術情報

GRUB 2 ブートローダーは、複数の文字列トークンで構成される grub.cfg ファイルより設定可能です。shim と呼ばれる初期ブートローダーがロードした直後に、設定ファイルがロードされ、GRUB の初期化で解析されます。パーサーの段階で、設定値はメモリーに格納される内部バッファーにコピーされます。長さが内部バッファーサイズよりも長い設定トークンは、バッファーオーバーフローの問題の原因となります。攻撃者はこの不具合を悪用して任意コードを実行し、マシンのブートプロセスをさらに乗っ取り、Secure Boot 保護機能を回避する可能性があります。その結果、未署名のバイナリーコードをロードし、システムの整合性をさらに脅かすことが可能になります。

背景情報

UEFI Secure Boot の説明と仕組み

Secure Boot は、UEFI Consortium によって開発された UEFI ファームウェアセキュリティー機能で、起動時に不変で署名済みのソフトウェアのみがロードされるようにするものです。Secure Boot は、暗号化と電子署名を活用して、ロードされたコードの信憑性、ソース、および整合性を検証します。これらの検証手順は、悪意のあるコードがロードされないようにし、特定タイプのルートキットのインストールなどの、攻撃を防ぐために行われます。UEFI および Secure Boot の詳細は、「UEFI Secure Boot in Modern Computer Security Solutions」を参照してください。 

信頼できるアプリケーションは、中心となる認証局によって署名されます。公開証明書はハードウェアに格納されるため、この証明書によって署名されたサードパーティーの EFI アプリケーションは正常にロードされます。

Secure Boot をサポートするバージョンの Red Hat Enterprise Linux では、署名済みの信頼できるアプリケーションは shim パッケージです。shin パッケージは、マシンのファームウェアによって最初にロードされるアプリケーションです。shim パッケージ自体が Red Hat の証明書を保持し、ロードが許可される信頼できるキーとコードハッシュの独自のデータベースも保持しています。このデータは、ブートローダーの署名 (GRUB 2) の検証に使用され、不正や改ざんがないことを確認します。検証に成功すると GRUB がロードされます。カーネルの署名が検証され、Red Hat の証明書またはユーザーが Allow DB に登録したハッシュと一致することを確認します。一致する場合は、GRUB によってカーネルがロードされ、ブートロードプロセスが終了します。

製品への影響

Red Hat Enterprise Linux (RHEL) 7 および 8、Red Hat Enterprise Atomic Host、および RHEL CoreOS (Openshift Container Platform 4 の一部) には脆弱なバージョンの GRUB 2 が含まれています。 

Red Hat Enterprise Linux 8

これらの更新の一部としてリリースされたカーネル内のハードニングにより、これまでの Red Hat Enterprise Linux 8 のカーネルバージョンは shim の allow リストには追加されていません。Secure Boot が有効な状態で実行し、古いバージョンのカーネルでブートする必要がある場合、ハッシュを手作業でトラストリストに登録する必要があります。これには、以下のコマンドを実行します。

# pesign -P -h -i /boot/vmlinuz-<version>

# mokutil --import-hash <hash value returned from pesign>

# reboot

Red Hat Enterprise Linux 7

これまでの Red Hat Enterprise Linux 7 のカーネルハッシュは shim の allow データベースに追加されているため、Secure Boot のユーザーは古いバージョンのカーネルでブートすることができます。 

RHEL Atomic Host

現時点では、 RHEL Atomic Host で shim バイナリーを更新することはできません。この問題を評価し、更新されたブートメディアを使用したノードのプロビジョニングが適切であるか判断します。

OpenShift Container Platform 4 (RHEL CoreOS)

現時点では、Red Hat は RHEL CoreOS の EFI システムパーティション (shim や grub を含む) の更新は同梱していません。定期的にノードを再プロビジョニングすることが、ベストプラクティスとなります。これには、更新された「ブートイメージ」を使用します。 お客様が受ける影響を評価し、その時点でブートイメージの更新が適切であるかを判断する必要があります。

この脆弱性は主に Secure Boot が有効になっているベアメタルシステムの整合性に影響するため、推奨される対処方法は新しいブートイメージの更新および使用のみになります。ブートイメージの更新手順は、ベアメタルインフラストラクチャーがどのようにプロビジョニングされているかによって異なります。これには、ブートインフラストラクチャーの PXE 設定を更新して新しいブートイメージを提供することが必要になることがあり、更新されたインストール ISO やベアメタルディスクイメージを使用したベアメタルシステムの再インストールが必要になることもあります。ご使用の環境を考慮し、ブートイメージを適切に更新するために OpenShift ドキュメントを参照してください。詳細は、「クラスターのベアメタルへのインストール」を参照してください。 

更新されたブートイメージでノードを再プロビジョニングする必要がある場合、再プロビジョニングするノードを遮断 (cordon) およびドレイン (drain) するために必要な処置を行う必要があります。クラスター全体の正常性を維持するため、ノードを 1 つずつ再プロビジョニングする必要があります。

以下のコマンドを実行して、ノードを遮断 (cordon) します。

$ oc adm cordon <node name>

以下のコマンドを実行して、ノードをドレイン (drain) します。

$ oc adm drain <node name>

上記のコマンドでノードが正常に遮断およびドレインされたら、ノードの再起動および再インストールを実行し、更新されたブートイメージで適切に再プロビジョニングされたことを確認します。

影響を受ける製品の更新

当初リリースされた shim パッケージは、新規バージョンに変更されました。更新された shim パッケージを利用できます。このパッケージは、すでにリリース済みの grub2、fwupd、および fwupdate パッケージとともに使用できます。当初の shim パッケージに関する詳細は、「https://access.redhat.com/ja/solutions/5277621」を参照してください。 影響を受けるバージョンをご使用のお客様は、この更新を適用することが強く推奨されます。

¹ Red Hat Enterprise Linux Extended Update Support サブスクリプションとは何ですか?

²Advanced mission critical Update Support (AUS) とは何ですか?

³Overview of the Red Hat Enterprise Linux for SAP Solutions subscription

⁴ Atomic Host

⁵ 更新の公開後にアドバイザリー/更新のリンクが追加されます。

⁶ 当初リリースされた shim パッケージは、新規バージョンに変更されました。更新された shim パッケージを利用できます。このパッケージは、すでにリリース済みの grub2、fwupd、および fwupdate パッケージとともに使用できます。当初の shim パッケージに関する詳細は、「https://access.redhat.com/ja/solutions/5277621」を参照してください。

⁷ 機能の既知のバグに対応するため、更新された dbxtool パッケージが RHEL 8 向けにリリースされました。DBX の更新を適用する手順は、記事「How to update the Secure Boot Forbidden Signature Database (DBX) with the latest UEFI Revocation List file」を参照してください。

診断

脆弱性検出スクリプトは、現在サポートされる Red Hat Enterprise Linux バージョンを対象としています。検出スクリプトは、Red Hat Enterprise Linux 上のレイヤード製品でも使用できます。レイヤード製品でスクリプトを実行できる権限が必要です。

Ansible Playbook

また、Ansible Playbook「CVE-2020-10713-update_fixit.yml」は以下で使用できます。この Playbook は関連するパッケージをすべて更新します。この Playbook を使用するには、更新するホストを HOSTS エクストラ変数 (extra var) で指定します。

ansible-playbook -e HOSTS=<myhosts> CVE-2020-10713-update_fixit--2020-07-29-1613.yml

正規の Playbook であることを確認するには、OpenPGP 分離署名 をダウンロードします。

よくある質問:

問: Secure Boot が有効であるかどうかを確認する方法はありますか。

答: 以下のコマンドを実行すると、Secure Boot が有効であるかをチェックできます。

    $ mokutil --sb-state

SecureBoot enabled

  注記: Secure Boot が無効になっているシステムでは、任意の変数を使用して mokutil コマンドを実行すると、以下が出力されます。  

# mokutil -l

EFI variables are not supported on this system

問: 更新されたパッケージのインストール後に再起動する必要はありますか。

答: 更新されたコンポーネントが使用されていることを確認するために再起動する必要があります。

問: コンテナーはどのような影響を受けますか。

答: Red Hat Enterprise Linux ベースのコンテナーは、この問題の影響を直接受けませんが、そのセキュリティーはホストカーネル環境の整合性に依存しています。コンテナーホストシステムの最新イメージと最新バージョンに更新することが推奨されます。使用中のコンテナーのプライバシーを保護するには、コンテナーホスト (Red Hat Enterprise Linux、Atomic Host など) に更新を適用およびデプロイする必要があります。 

問: Red Hat Enterprise Linux 7 を実行していますが、カーネルバージョンを更新できません。現在のカーネルバージョンのハッシュ値を信頼できる DB に登録する必要がありますか。

答: その必要はありません。Red Hat Enterprise Linux 7 の古いカーネルバージョンは、自動的に shim の allow リストに追加されます。

問: Red Hat Enterprise Linux 8 を実行していますが、現在のカーネルバージョンのハッシュ値を信頼できる DB に登録する必要がありますか。

答: 登録する必要があります。Red Hat Enterprise Linux 8 の古いカーネルバージョンはデフォルトでは信頼されません。これまでのカーネルバージョンをすべてブート可能にするには、root ユーザーとして以下のコマンドを実行します。

# pesign -P -h -i /boot/vmlinuz-<version>

# mokutil --import-hash <hash value returned from pesign command>

# reboot

問: Secure Boot を使用しない場合、この更新を GRUB に適用した後に、変更を加えないままこれまでのバージョンの RHEL 7 および 8 カーネルでブートしてもよいですか。 

答: はい。Secure Boot が無効な場合は、署名の検証が実行されないため、何もしなくてもこれまでのバージョンのカーネルはブート可能です。

問: 新しい DBX 更新は UEFI ファームウェアに適用されますか。

答: GRUB のセキュリティーに不具合があるため、これまでの Red Hat Secure Boot 署名は取り消され、Disallow DB (DBX) データベースに追加されます。dbxtool の更新が適用されると、新しい署名が使用されます。新しい DBX ファイルは更新に含まれ、古い Red Hat キーの取り消しも含まれています。しかし、dbxupdate はデフォルトでは実行されず、古い鍵を除外したい IT の専門家を対象としています。必須の新しい dbxtool 自動更新が数ヶ月以内にリリースされる予定です。これにより、すべてのお客様の Red Hat キーが無期限で取り消しされます。  

問: この脆弱性は、Secure Boot の使用に関わらず、実行されるプログラムコードに影響します。Secure Boot が有効になっているシステムとそうでないシステムで脆弱性の影響が異なるのはなぜでしょうか。

答: Secure Boot は、無変更の信頼できる署名済みのコードのみがマシンのファームウェアおよび後続のローダーコンポーネントによってロードされる仕組みになっています。よって、Secure Boot によって、ブート段階 (ブートローダー、カーネル、カーネルモジュール) で信頼できないソフトウェアのロードを防ぐ軽減策として機能するセキュリティーの境界線が追加されます。GRUB 2 の不具合によって任意コードの実行が可能になるため、攻撃者はこれを悪用し、Security Boot によるセキュリティーの境界線を越えて署名の確認を回避したり、信頼できないコードを実行することができるため、ロードされたカーネルの整合性を脅かすことになります。 

Secure Boot が無効である場合は署名の検証は行われません。そのため、Security Boot のセキュリティー境界線を越えることはありません。この不具合では、任意コードのロードが可能になりますが、Secure Boot が無効である GRUB の場合は、任意コードの実行を可能にする別の不具合と見なされます。

問: RHSA-2020:3216 または RHSA-2020:3217 の適用後、POST の後にシステムがハングし、grub メニューがロードされない場合はどうしたらよいですか。

答: ソリューションの記事 https://access.redhat.com/ja/solutions/5277621 を参照してください。Red Hat は 2020 年 8 月 1 日 (土) に、この問題に対応する最新の shim パッケージをリリースしました。RHSA-2020:3216 または RHSA-2020:3217 の一部としてリリースされた旧バージョンの shim パッケージを使用せずに、RHBA-2020:3262 および RHBA-2020:3265 とリリースされた shim パッケージ (またはそれ以降) を使用することが強く推奨されます。  

謝辞

Red Hat は、この脆弱性を発見し、報告していただいた Eclypsium の Jesse Michael および Mickey Shkatov 両氏に感謝いたします。また、Red Hat は本問題の対応に協力していただいた業界のパートナーならびに GNU GRUB コミュニティーに感謝いたします。 

参考資料

• Eclypsium - There's a Hole in the Boot 
• How to apply the updated DBX file within dbxtool updates
• Working with GRUB 2
• UEFI Secure Boot in Modern Computer Security Solutions
• GPG を使用して Product Security の署名済みコンテンツを検証する