オペレーティングシステムのローダ署名がSecureBoot除外データベース(「dbx」)に見つかりました。起動可能なデバイスのうち、セキュア起動確認に合格したデバイスはありません。

オペレーティングシステムのローダ署名がSecureBoot除外データベース(「dbx」)に見つかりました。起動可能なデバイスのうち、セキュア起動確認に合格したデバイスはありません。

次のウェブサイトからPop!_OS 22.04 LTS(NVIDIA)をダウンロードしました。公式ウェブサイト、チェックサムを確認し、ペンドライブにフラッシュして起動を試みます。

Webサイトが推奨するようにセキュアブートを無効にすることを忘れてしまったため、予想通りエラーメッセージが表示されました。しかし、電子メールの実際の内容は私を驚かせました。

オペレーティングシステムのローダ署名がSecureBoot除外データベース(「dbx」)に見つかりました。起動可能なデバイスのうち、セキュア起動確認に合格したデバイスはありません。

署名データベースで署名が見つからないと予想しましたが、入らないようにするデータベース。

~によるとこのウェブサイト:

dbx、「署名データベースの禁止」。ここでのエントリは通常、特定のUEFIバイナリのSHA256ハッシュです。つまり、「db」リストの証明書で署名されているが、後で間違っていることが判明したバイナリ(ファームウェアを破損するセキュリティ上の脆弱性など)です。したがって、これは「ブロック」のリストです。

System76が提供したソフトウェア署名がかつて有効でしたが、後で間違っていることが判明したのはなぜですか?

これはPop!_OSの潜在的な脆弱性を示す信号ですか?

ベストアンサー1

2020年半ばにプロジェクトCVE-2020-10713またはBootHole設立する。acpiこれは、GRUB2とセキュアブートを使用し、セキュアブート互換構成にGRUBモジュールを含むほぼすべての展開に影響します。その後、セキュリティ研究者は他の同様の脆弱性を見つけるために起動プロセスにさらに注意を払いました。

これにより、2021年3月にGRUB2で追加の脆弱性セットが発見、修正、リリースされました。これに加えて、Debianは以前のSecure Boot署名キーをキャンセルし、新しいキーを生成し、ブートローダ署名プロセスをいくつか変更する必要があります。 Ubuntuにも同様のセキュリティブートインフラストラクチャがあるため、その人も同じことをしなければなりません。

Debian/Ubuntu から Secure Boot インフラストラクチャをコピーする他のディストリビューションも同じことを行う必要があります。セキュリティ研究者プロジェクトの別の部分は、shimx64.efi脆弱なGRUBとバージョンのハッシュリストを収集し、Secure Boot署名キーをキャンセルすることです。このリストは将来のセキュアブートファームウェア用の除外データベースに追加され、最終的にセキュアブート除外データベースの更新として既存のシステムに展開されます。

2022年8月9日、マイクロソフトは脆弱なGRUBバージョンの除外を含むWindowsセキュリティブート除外データベースの更新をリリースしました。また、fwupdLinux/システム用のセキュアブートdbxのアップデートもリリースしましたfwupdmgr。すべての主要なオペレーティングシステムが含まれるようにするために、Linuxディストリビューションとオペレーティングシステムベンダーの間にある程度の調整があると仮定するのが妥当です。

Pop!_OS のブートコンポーネントが最新の除外リストと一致する場合、これはコンポーネントが 2021 年 3 月より前の Debian から派生したことを意味します。つまり、Debian 10.9以下と同等のレベルにあるという意味です。 Pop!_OSがいくつかのアップデートをスキップしているようです。

もちろん、彼らはセキュアブートを無効にすることをお勧めしますが、Pop!_OSはそのUbuntuバージョンに基づいているため、UbuntuのセキュアブートサポートはPop!_OS 22.04 LTSも機能的なセキュアブートサポートを実装できることを示唆しています。おそらく、System76(Pop!_OS開発者)がマイクロソフトからセキュアブート証明書を受け取ることをスキップすることにしました。私にとって、これはPop!_OSの焦点がコンテンツではなくスタイルに焦点を当てることができることを意味します。

基本的に、2022年8月9日にセキュアブートを撤回する目的は、脆弱なコンポーネントの使用中に感じる誤ったセキュリティセンスを排除することです。システムは、もともとセキュアブートを持たないシステムよりも脆弱ではありません。 。

システムが物理的に安全である場合、攻撃者がこれらの脆弱性を悪用してシステムに侵入するための実用的な方法はないはずです。ただし、セキュアブートを使用してEvil Maidタイプの攻撃を「意図した」攻撃者レベルよりも困難にする場合、Pop!_OSは現在そのユースケースの間違った選択になる可能性があります。

おすすめ記事