UEFIセキュアブートを備えたマシンでハイバネーションはどのようにサポートされますか？
私は EFIセキュアブート について学習してきました。これは、署名されたブートローダーとカーネルのみをロードできるようにブートプロセスをロックダウンして「ブートキット」を防止しようとします。
ハイバネーションは主要な攻撃ベクトルのようです。ハイバネーション（suspend-to-diskとも呼ばれます）は、カーネルメモリのすべてを含むメモリの状態全体をディスクに書き込むことを含みます。この状態がディスクに書き込まれた後、電源を切ることができます。電源が回復したら、この状態をディスクから読み取り、メモリに書き込むことによって再開します。マルウェアがカーネルに挿入されるようにカーネルメモリを変更するなど、攻撃者がディスク上のメモリの休止状態を変更できないようにするものは何ですか？ユーザーが再開すると、感染したOSカーネルがメモリに読み込まれるようです。
同様に、悪意のあるマルウェアは、巧妙に細工された休止状態ファイル（実際の休止状態ファイルの修正バージョンを含み、実行中のカーネルにマルウェアを挿入するように修正されたもの）を作成し、強制的に再起動する可能性があります。再起動すると、休止状態のイメージがメモリに読み込まれると思います。これは、UEFIセキュアブートのセキュリティ目標に違反しているようです。
どういうわけか混乱したりねじれたりしたのではないかと思います。誰でもこれを片付けることができますか？ハイバネーションはUEFIセキュアブートと互換性がありますか？ UEFIセキュアブートの目標にセキュリティリスクをもたらしますか。その場合、展開されたUEFIセキュアブートの使用でこれらのリスクにどのように対処しますか？
ハイバネーションはUEFIセキュアブートと互換性がありますか？
そのためには、UEFI仕様のセクション27を確認する必要があります。この仕様では、使用中のプロトコルの完全な説明が表示されます。私はそれらを簡単に要約します-これは大まかな解釈であり、ゆるいエッジを持っている可能性があります（決定的な解釈が必要な場合は、UEFI関係者の1人を見つけてください:)）：
EFI_AUTHENTICATION_INFO_PROTOCOLセクションは、さまざまな実装の認証情報を取得および設定するためのいくつかのメソッドを定義します。- UEFIドライバーの署名（UEFIファームウェアのサポートアプリケーション）。 UEFI実行可能ファイルはWindows PEイメージファイル形式に基づいているため、これはEFIモジュールのオーセンティケードに相当すると考えることができます。
EFI_HASH_PROTOCOLは、ハッシュ用のプログラミングAPIを提供します。次に、ジューシーな部分：ファームウェア/ OSキー交換。これは、プラットフォームキーの登録を担当します。 EFIは2つのモードを指します。
- 設定モード
- ユーザーモード前者のモードは登録済みキーのないセットアップを指し、後者は登録済みキーのあるセットアップを指します。
登録されたキーは、イメージ署名が信頼される秘密キーのルートです。
- OSファームウェアへの公開鍵の受け渡しセクションは、まさにそのように聞こえます-オペレーティングシステムと通信するために使用する必要がある鍵をファームウェアに通知するためのプロトコルシステム。
- UEFIイメージ検証とは、UEFIイメージ（ブートローダーなど）を署名データベースと照合するプロセスを指します。
- 署名データベースは、プラットフォームキーで署名された有効なUEFIイメージのリストです。起動するには、イメージが署名データベースの署名と一致している必要があります。
これらのEFI仕様の詳細をカバーする理由は、UEFIセキュアブート仕様がUEFIセキュアブートの拡張範囲をカバーすることを指摘することです。つまり、次の2つのことを達成することを目的としています。
- UEFIローダーは、シグネチャデータベースにシグネチャが存在するEFIイメージのみをロードしますifUEFIセキュアブートが有効であり、プラットフォームキーが登録されている（これはプラットフォームの所有者によって行われます）。
- UEFI仕様は、オペレーティングシステムとUEFIファームウェアの間で情報をやり取りして、署名データベースとEFI変数を問い合わせる手段を提供します。
ここでの重要な点は、ロードされたEFIイメージ、またはサインオンを強制するためにロードされたOSカーネルanything続いてロードします。
例えば;
- Fedoraはカーネルとそれぞれのモジュールに対してずっと署名を強制します- this status updateand this を参照してください
- Fedora EFIブートプロセスから出てきたUEFIシムの この記事 を読んでください。このシムはオプションで、カーネルなどのブートプロセスの後の部分で署名チェックを無効にするためにUEFI変数を設定できます。 詳細
Ubuntu自体 カーネルに署名しません ：
したがって、ブートローダーバイナリの認証のみが必要になります。 Ubuntuは、署名されたカーネルイメージやカーネルモジュールを必要としません。
それでは、UEFIに戻りましょう。
同様に、悪意のあるマルウェアは、巧妙に細工された休止状態ファイル（実際の休止状態ファイルの修正バージョンを含み、実行中のカーネルにマルウェアを挿入するように修正されたもの）を作成し、強制的に再起動する可能性があります。再起動すると、休止状態のイメージがメモリに読み込まれると思います。これは、UEFIセキュアブートのセキュリティ目標に違反しているようです。
はい。これは 現在のオペレーティングシステム に最適な攻撃ベクトルであり、その起源は pagefile attack にあります。
カーネル（Windowsカーネルの場合に使用されていた）がデータをディスクからRAMに盲目的にロードしたため、これらの攻撃は両方とも機能します。正しい修正を行うと、ドライバーの変更、独自のドライバーのインストールなどが可能になり、リング0と1つの侵害されたシステムを呼び出します。
UEFIセキュアブート環境では、EFIファームウェアは、ブートローダーがEFIファームウェアをシャットダウンしてオペレーティングシステムに移行するまでに改ざんされていないことを保証します。それだけです。 UEFIセキュアブートは、読み込まれたオペレーティングシステムが変更されていないこと、または読み込まれたオペレーティングシステムが変更されたイメージを起動から読み込んだことを保証しません。確認して適用するのはオペレーティングシステム次第です。
今いくつかの個人的な考え：
UEFIセキュアブートの目標にセキュリティリスクをもたらしますか
UEFIセキュアブートに期待するのは、正常な状態のカーネルであるという意味で、そうだと思います。それはあなたが得ることが保証されるものではありませんが、それはあなたが期待するものです。
uEFIセキュアブートの展開された使用でこれらのリスクにどのように対処しますか？
これらのリスクは、AuthentiCodeなどのコード署名イニシアチブによって、より正確に軽減されていると思います。たとえば、64ビットWindowsでは、F8とブートメニューを含む特別なダンスを実行しない限り、署名されていないドライバーコードは読み込まれません。ほとんどのMicrosoft画像は署名されており、-わかりませんが、推測します-ntkrnlmp.exeは、Microsoft EFIブートローダーによって署名および検証されます。
ご覧のように、Fedoraなどのディストリビューションは、検証済みのブートローダーを入手しただけではシステム全体のセキュリティがほとんど意味がないため、このアプローチを採用しています。
このプロセスの次の段階は、休止状態などの攻撃経路を閉じることだと思います。たとえば、ページファイル攻撃はマイクロソフトによって修正されました。たとえば、EFIファームウェアに格納されているキーの1つを使用して生成でき、ブートローダーまたはカーネルのいずれかでブート時に検証できる署名済みチェックサムが必要だと考える場合は、簡単に修正できます。
脆弱であるが対処可能
User2213が示したように、ハイバネーションファイル攻撃は、UEFIセキュアブート仕様の何によっても防止されません。
解決策は、システムボリュームと、ページング/ハイバネーションデータを含むすべてのボリュームでフルディスク暗号化を使用することです。 WindowsにはBitlockerがあり、LinuxにはLUKSがあります。
通常のWindowsインストールでは、デフォルトでhiberfil.sysが格納されているため、この攻撃を防ぐためにC：\を暗号化するだけで済みます。
最近のCPUでAESを実行するためのオーバーヘッドが低いため、すべてのドライブを暗号化することをお勧めします。 Intel CPUは約10年間AESのハードウェアアクセラレーションをサポートしてきました。
実際、OSが実行する必要があるのは、メモリイメージが更新されていないことを検証することだけです。これは、OSブートローダーがロード時にディスク上のイメージをハッシュすることで確認できます。ハッシュが安全な場所に保存され、ファームウェアで検証されたブートローダー内からイメージが検証される限り、すべてが安全です。