UEFIセキュリティパート3

UEFIセキュリティについて引き続き説明します。
今回は、ACPI S3（スリープモード）の実装で2014年後半に公開された深刻な脆弱性、その動作と結果についてお話します。 この脆弱性の主な「トリック」は、以前はまったく問題とは見なされていなかったUEFIセキュリティ問題のクラス全体を明らかにしたため、別の記事に値することです。
サイクルの前の記事を一 度も読んでいない人のために-私は最初にそれらを読むことを提案します、私はカットの下で残りを待ちます。

パート3。 ACPI S3

ほんの少しの教育プログラム

SMMとは異なり、ACPI S3については、平均的なユーザーはほとんどの場合、疑いさえしていません。 スリープモード、ラップトップまたはPCを過去10年間にリリースした人なら誰でも知っています。
ACPI標準は、 私が最近書いた最新バージョンの変更について、いわゆるセットを定義しています スリープ状態 。次のいずれかのシステムがあります。

• S0-作業中 、つまり 通常の操作では、すべてのデバイスがオンになっています。 この状態の中で、システム製造業者は他の状態の束を定義する権利を持っています： P状態、 C状態、 T状態など、私はそれらについて改めて話しましょう。
• S1-プロセッサコンテキストが維持された状態でのスリープ 、別名Power on Suspend、つまり すべてのプロセッサコアがHLTコマンドを実行してスタンドになっていますが、すべてのキャッシュとRAMは有効で更新されており、すべてのS0専用ラインからの電力は削除されています。 この状態からの復帰には約10 msかかりますが、そのうちの約90％は、S0専用回線に電力を供給した後の定常状態モードの予測です。 この状態のCPU、チップセット、またはデバイスのレジスタはリセットされないため、この記事には興味がありません。
• S2 / S3-RAMへのサスペンド 、つまり メモリの内容は有効で更新されたままであり、プロセッサとチップセットの一部は完全に無効になり、ほぼすべてのレジスタのコンテキストと内容が失われます。 S2とS3の違いは最小限であり、ほとんどの場合、S2はまったく別の状態に割り当てられていません。 S3から起動した後、プロセッサはResetVectorからコードの実行を開始します。 適切に「ウェイクアップ」するために、彼は自分自身とチップセットのコンテキスト全体を復元する必要があります。 この段階で、ファームウェアの開発者は、この記事で説明するいくつかの水中レーキを待っています。
• S4-ディスクへのサスペンド 、つまり メモリの内容がディスクにフラッシュされ、システムはすべてのデバイスと電源をオフにします。 スイッチをオンにすると、システムは通常どおり起動し、UEFIの観点から見ると、S4とS5の間に実質的な違いはありません（FastBootを無効にした場合、まったく違いはありません）。
• S5-ソフトオフ 、つまり システムはオフですが、スタンバイ電源は存在します。 S4 / S5から、システムはRTC信号、デバイスからのWake信号、または電源ボタンを押すことで出力できます。

UEFIでのS3の実装方法

「ウェイクアップ」時にコンテキストを復元するには、まずどこかに保存する必要があります。 同時に、プロセッサとチップセットアーキテクチャの特定の機能に執着しすぎないこと、および後でデバッグで死ぬことがないように、コンテキストの保存と復元をできるだけ透過的にすることをお勧めします。 なぜなら S3のパフォーマンスは、ほとんどすべての最新のPCの非常に重要な特性です。ただし、稼働時間の長いサーバーを除き、コンテキストを保存および復元する技術は2004年の早い時期にIntelエンジニアによって開発され、 EFI S3 BootScriptと呼ばれていました。 それ以来、仕様は何度も改良され、最新バージョンはUEFI PI仕様の第6巻になりました。
その本質は次のとおりです。基本的なデバイスの初期化が行われるPEIフェーズの実行後。 プロセッサ、キャッシュ、およびRAM、システムは現在のブートモードを決定します。
1.このモードがS3 Resumeと異なる場合、ダウンロードは通常どおり続行され、PEIはDXEマネージャーで終了します。DXEマネージャーは新しい空のS3 BootScriptを作成し、使用可能なすべてのDXEドライバーを起動します。 このような各ドライバーは、担当するデバイスの最終初期化を実行し、S3から戻るときにデバイスの初期化を繰り返すために実行する必要があるコマンドをS3 BootScriptに追加します。 コマンドは次のようなものです（リストはPI 1.4仕様から取られていますが、特定の実装では非標準のものも見つけることができます）。

• IO_WRITE-指定された値を指定されたCPU IOポートに書き込みます
• IO_READ_WRITE-指定されたマスクに従って、指定されたCPU IOポートの値を変更します
• IO_POLL-指定された条件が満たされるまで、指定されたIOポートから読み取りますが、指定されたタイムアウト以下
• MEM_WRITE-指定された値を指定された物理アドレスに書き込みます
• MEM_READ_WRITE-指定されたマスクに従って、指定された物理アドレスの値を変更します
• MEM_POLL-指定された条件が満たされるまで、指定されたアドレスで読み取られますが、指定されたタイムアウト以下になります
• PCI_CONFIG_WRITE-指定されたPCIデバイスの構成スペースの指定されたアドレスに指定された値を書き込みます
• PCI_CONFIG_READ_WRITE-指定されたマスクに従って、指定されたPCIデバイスの構成スペース内の指定されたアドレスの値を変更します
• PCI_CONFIG_POLL-指定された条件が満たされるまで、指定されたPCIデバイスの構成スペース内の指定されたアドレスで読み取りますが、指定されたタイムアウト以下になります
• SMBUS_EXECUTE-指定されたコマンドをSMBusバス上の指定されたデバイスに送信します
• STALL-指定されたマイクロ秒数待つ
• DISPATCH-指定されたアドレスでコードを実行

上記のコマンドは、すべての初期化を実行するPEIドライバーに制御を単純に転送する最後のコマンドを考慮すると、特にデバイスを再初期化するのに十分ですが、これは、残りのコマンドを省くことができない特に困難な場合にのみ必要です。
DXEフェーズの終了後、ディスパッチャは結果のS3 BootScriptをAcpiNVSメモリに保存します。AcpiNVSメモリには、ACPIテーブルと、OSがACPIで正しく機能するために必要なその他のデータが含まれます。
2.ブート時に、システムがDXEマネージャーではなくS3 Resumeにあることが判明した場合、BootScriptExecutorという美しい名前のPEIモジュールが起動され、BootScriptが実行され、最後の通常のブート以降にメモリに慎重に保存され、OSに制御が転送されます。起動し、ユーザーを喜ばせます。
言葉で、彼は説明したように、今では同じこと-仕様からの写真：

水中熊手

これはすべて約10年間正常に機能し、2014年の終わりに狭いサークルでよく知られた仲間、ラファルヴォイチュチュクとコーリーカレンバーグが明らかで非常に危険な攻撃であることが判明するまで、ほとんど誰もそのトリックを見ませんでした。 S3 BootScriptを格納するメモリ領域（AcpiNVSなど）は変更から保護されていないことが判明しました。 はい、OSはそれをサービス1として認識し、コンテンツ自体を台無しにしませんが、管理者権限を持つ攻撃者はそれを行います。
変更は非常に異なる場合がありますが、 SPIチップでの任意のコードフラッシュ、およびSMMへの不正アクセスに対する保護を提供する保護メカニズムのほとんどは、プロセッサおよびチップセットレジスタを介して構成されているため、これらのメカニズムを正常にバイパスするには、メモリ内のBootScriptを見つけるだけで十分です（これは簡単です）必要なレジスタ（難易度なし）を変更し、次のS3レジューム保護がオンにならないように変更します。 変わり、眠りに落ち、目を覚ましなさい-op、そして王は裸です！ SPIチップとSMMからの保護の削除を脅かすもの-前のパートですでに書いたように、繰り返しはしませんが、良い結果で終わることはありません。
興味深いことに、Intelのエンジニアはこの攻撃を予見し、事前に保護を実装しました。 SmmLockBox 。 保護は非常に簡単です。スクリプトのコンパイルが終了すると、SMRAMに完全にコピーされますが、元のBootScriptは削除されません。 S3から回復するとき、SMIハンドラーが呼び出され、元のBootScriptがSMRAMのコピーと一致することを確認し、そうでない場合は、変更されたBootScriptをコピーで上書きするか、マシンを再起動します（これはより安全ですが、ユーザーはRAMからすべてのデータを失います）。 問題は、SmmLockBoxが時間内に実装する時間がないことであり、RafalとCoreyが脆弱性をテストしたとき、攻撃を受けないマザーボードはIntelのUEFI開発キットだけであることが判明しました。
攻撃が公開された後、 IBVは急いで元のSmmLockBoxまたは同じアイデアに基づく類似物のいずれかを導入し始めましたが、この実装はさまざまな理由で停止することがよくありました。 たとえば、AMDプロセッサを搭載したシステムでは、SMMはDXEフェーズで初期化されたため、S3 Resumeを使用したPEIからのSMIハンドラーの呼び出しは失敗し、S3はまったく動作しなくなりました。
ただし、現時点では、少なくとも耳の端までセキュリティについて聞いているすべてのベンダーは、すでに何らかの方法でこの問題を解決しています。また、ファームウェアが2015年6月より新しく、システムの製造元が悪口でない場合、システムは直接攻撃する可能性が高いですS3 BootScriptは影響を受けなくなりました。

プラットフォームメーカーの豚

パニックが少し落ち着き、BootScriptがSMRAMに正常にプッシュされた後（目の前にそれを保存する必要があるのは明らかですが、これについては最後の部分で書きました）、IntelとAMDのエンジニアがそれを知らずに突然判明しました、彼らはプラットフォームの所有者にいくつかのPEIモジュールに直面してまともな豚を植えました。これは a ）BootScriptのすぐ隣のメモリにコピーされ、 b ）DISPATCHコマンドによって何十回も呼び出され、 c ）SMRAMにスペースを確保するのに十分な大きさでした十分ではありません。
したがって、BootScript自体を一般的に変更することなく、任意のコードの実行を整理できます。代わりに、そのようなモジュールの1つのエントリポイントを変更します。 S3の動作を中断せずにこのようなモジュールを削除することはできませんでしたが、解決策が見つかりました-メモリにコピーする代わりに、DXEボリュームの展開された部分に転送され、SPIPAチップからコードが直接呼び出されるようにDISPATCHコマンドが修正されました。 これはRAMよりも少し遅いことが判明しましたが、ブタはなんとかそれを追い出しました。 この方法で攻撃できるシステムの数はわかりませんが、多くのシステムがあると思われます。

忘れっぽい紳士

人はエラーの影響を受けず、DXEドライバーの開発者も人間であり、BootScriptに重要なレジスターを追加することを忘れてしまうことがあります。S3の後、このレジスターは元の値になります。 ほとんどの場合、このような物忘れはS3後の軽微な不具合につながるだけですが、マーフィーの法則は、重要なレジスタを忘れると忘れてしまうと言っています。 忘れっぽさの最新の注目すべき例は、今年の5月下旬にAppleラップトップファームウェアで公開された脆弱性です。エンジニアはS3 BootScriptのPRレジスタにエントリを追加するのを忘れ、S3の後、SPIチップはファームウェア自体によって保護されなくなりました。 結局のところ、ふたを閉じるのは非常に便利です。また、フラッシュROMを入手してBIOSでコードを書くことができるので、Appleは再びシンプルで使いやすくなっています。 ケースが独特だと思う場合-PCでChipsecユーティリティを実行し、S3の前後に作成されたレポートを比較することをお勧めします。 同時に、驚きが起こる可能性があります。

私はS3をオフにし、草が成長しません

これについて、より表現力豊かで、少しわいせつなだけで、初めて問題に遭遇したとき、私は叫んだ。 残念ながら、このオプションは常に可能というわけではありません（SSDのS4の速度はほとんど変わりませんが、信頼性は大きく異なりますが、スクリプトやエグゼキューターとのダンスは必要ありません）、さらに、ファームウェアを変更してS3を厳しく無効にしなかった場合、攻撃者はシステムUEFIシェルで実行し、S3を簡単にオンにします。 次のパートでは、このような厄介な運命を避ける方法を説明しようとしますが、簡単に-SecureBootをオンにして使用します。調理できるなら、それはまったく悪ではありません。

自信の危機

S3 BootScriptを使用したこの全体の話から、UEFIでの10年間の気楽な開発が今だけ真剣に解決され始めたという興味深い問題が明らかになりました。 問題は、「安全な」ファームウェアが、OSがアクセスした、またはアクセスしたものを信頼できないことです。 デバイスを個別にリセットおよび初期化する必要があり、メモリをクリアし、そこから何も使用しないでください（そこからコードをランダムに呼び出さないでください！）、ランタイムサービスはReadyToBootイベントの後は使用できません（攻撃者は既にそれらをフックしていることがあります）一般に、堅固な地雷原で、私は少しつまずきました-そして今、あなたはすでに他の誰かのコードの完全なBIOS、バックドアのバックドア、SMRAMの正直なドライバーが場所を持っていません。 そのため、プラットフォームメーカーはハードウェアソリューションの救済を求めています。誰かが検証済みブートを実装し、誰かがセキュリティコプロセッサーにS3 BootScriptを保存し、誰かが自分の暗号チップを開発し、誰かがスコアを付けてUEFIフォーラムソリューションを手に入れるのを待っています低下します。
そのため、Intelは、Skylakeに興味深いSGXテクノロジーを追加しました。これは、システム内の他のすべてからコードやデータの個々の部分を分離するために使用できます。 このテクノロジーは非常においしいように見えますが、第一に、プログラミングが困難であり、第二に、IntelのみがSkylakeにのみ搭載しています。
「安全な」OSの部分では、ファームウェアに対する不信のレベルはまったく同じであり、2009年以来話題になっているSTMテクノロジーは、最近になって正式に導入され 、「戦闘中」はここでテストされていませんが、役に立つ場合があります。 両手が届くと、それについて書きます。

おわりに

さて、S3 BootScriptの問題は背後にあります。次の部分では、NVRAMとSecureBootへの攻撃について、またBIOSパスワードが正直な人々からのものである理由について説明します。
良い伝統により、私はこの記事の同志がここに英語の愛好家に助言します 同じトピックのd_olex 。 深刻さ、深さ、コード、写真がありますが、ここでの私の言い回しとは異なります。
安全なファームウェアをお読みいただきありがとうございます。