UEFIセキュリティについて、パート0と最初

むかしむかし、2014年の初めに、ほとんどのUEFI実装のセキュリティ状態を「 半神話的 」と呼びました。 それから1年半が経ち、物事は慎重に動き出しましたが、これまでのところ、エンドユーザー向けの多くのPCメーカーはこの非常に安全性にほとんど注意を払っていません。

この記事では、UEFIの脅威モデルと攻撃ベクトル、およびBIOSチップの内容の上書きに対する保護に焦点を当てます。これは、攻撃の可能性のある結果を最も破壊するものです。

UEFI保護がどのように機能するか、および最新のシステムで修正されていない特定の脆弱性に関心がある場合は、Catへようこそ。

パートゼロ。 はじめに

私はかなり長い間、 UEFI互換ファームウェアのセキュリティに興味があり、ほぼ2年間専門的にやっています。 この記事を書いた理由は、UEFIセキュリティに関する情報がインターネットのロシア語部分にほとんど完全に存在しないことでした。ただし、このテーマにあまり精通していない人々が作った有名な英語圏の研究者による記事の翻訳は例外です。 このギャップは徐々に埋める必要があります、なぜなら それ以外の場合は、「フリーソフトウェアに対するセキュアブート」、「UEFI-悪魔の創造」などのさまざまなスローガンで満たされます。 事前にこの言語について謝罪します。長い間ロシア語を話したり書いたりしないと、ロシア語のことを考えるのをやめてしまいます。そのため、構造は非常に奇妙になります。

脅威モデル

保護と脆弱性について話す前に、脅威モデルについて少し話しましょう。

一度にすべてに対して防御することはできません。 たとえば、核爆発の損傷効果や宇宙での作業中の障害からファームウェアを保護することは、この記事では考慮しませんが、関連分野の専門家から同様の記事を読みたいと思います。

アクセスレベル

攻撃者に対していくつかのレベルのアクセスを定義し、「平均的な」UEFI実装が何にどの程度成功するかを確認します。

-第1レベルの攻撃者は、システムに物理的にアクセスし、OSをロードし、UEFI設定を変更し、プログラマーの元のコードの代わりにUEFIコードをフラッシュし、マットのジャンパーを再配置できます。 回路基板、短絡、超小型回路の結論など

-第2レベルの攻撃者はシステムに物理的にアクセスできますが、プログラマーはいません。

-第3レベルの攻撃者は、管理者モードでシステムにリモートアクセスできます。

残りのケースは考慮しません。 ボールに乗るチップを変更できる、より強力な攻撃者からは、UEFIで防御するものは実質的になく、管理者権限のない弱いものはOSを停止します。

攻撃ベクトル

ここで、危険を減らすために、主なベクトルと攻撃が成功した場合の結果を定義します。

1.メインファームウェアの保存 （最新システムの95％ -SPIインターフェイスを備えた1-2のNORフラッシュチップ）

攻撃の本質-ファームウェアにコードを挿入し、既存のコードの一部を削除し、盗み、殺し、ガチョウについて黙ってください。

攻撃の影響は、ファームウェア、ハードウェア、OSの完全な制御の取得から、最悪の場合のDoSにまで及びます。 物理的な攻撃者はどのような場合でもDoSを手配できます（給与計算に大きなドライバーを使用します-これはあなたにとってDoSです）。したがって、第1レベルと第2レベルの攻撃者についてはDoSについては触れません。

2. SMMのコード

一番下の行は、すべての物理メモリなど、特に特権のあるプロセッサモードにアクセスできることです。

その結果、最良の場合はファームウェアリポジトリにアクセスし、最悪の場合はOSおよびハイパーバイザー保護メカニズムをバイパスします（ただし、OSレベルで回避される可能性がありますが、SMMからははるかに簡単です）。

3. PCIデバイスのファームウェアの保存

結論-コードをPCIデバイス（オプションROMでもあります）のファームウェア（たとえば、ネットワークカードやThunderboltコントローラー）に挿入します。UEFIは、デバイスが初期化されるとこのコードを実行します。

結果-最良の場合、最悪の場合、ポイント1を参照してください-ほとんど同じです、私たちはずっと後で開始するため、いくつかのものは既に構成され、ブロックされています。

4. NVRAMの変数

一番下の行は、非表示の設定を含むUEFI設定を変更できることです。

結果-最良の場合、すべての保護をオフにして、すぐに手順1に進み、最悪の場合は再びdoSにすることができます（ガベージをNVRAMに書き込み、再起動し、何が起こったのかを確認します）。

5. SecureBoot

結論-UEFIシェルを含む任意のOSをロードする機会が得られます。

結果-最良の場合、UEFIシェルをロードしてすぐにステップ4に表示されることが判明し、最悪の場合、標準のブートローダーを変更されたブートローダーに置き換えます。したがって、警戒ユーザーがSecureBootをオンに戻すまで、OSで自身を保護します。

パート1 メインファームウェアのストレージ内の書き込み保護

1.コード実行前のファームウェアまたはその一部のハードウェア検証

適切に実装された場合、 Intel BootGuardとAMD Hardware-Validated Bootの 3つのレベルすべての攻撃者からファームウェアを保護する、私たちのリストで最も深刻なテクノロジー。 細部が大きく異なり、同じタスクを実行します。マザーボードメーカーのデジタル署名によって署名されたファームウェアの小さな部分の整合性をチェックし、キーハッシュがチップセットにフラッシュされます。 テストが成功した場合はファームウェアが起動し、失敗した場合はすべて設定に依存します。 両方のテクノロジーは、後続のブートステージに「ハードウェアの信頼のルート」を提供し、ファームウェアはチップセットがブートストラップコードをチェックする信頼チェーンを構築できます。このコードはPEIボリュームをチェックし、 DXEボリュームをチェックします。 OSブートローダーの署名。 このように保護されたファームウェアの一部の変更は、ほとんどの場合、通常のDoSにつながります。

そのような保護の裏側は、システムの正当なユーザーでさえファームウェアを変更できないこと、チップセットまたはSoC障害の場合にマザーボードを修復することの難しさです（そして、異なるハッシュを持つ使用済みのものではなく、クリーンなものに変更することは良いことです。最初の場合、検証済みのドライバーを削除しようとすることができますイメージからブートしますが、2番目のイメージでは何も役に立ちません）。

これらのテクノロジーは、Intel HaswellおよびAMD Trinityからサポートされており、それらに対する実際の攻撃はわかりませんが、現在は2つ半の企業ノートブックモデルで使用されており、ファームウェアとOSを変更する可能性があるため、状況があまり変わらないことを望みますデバイスを他の誰かと区別します。

IntelおよびAMDから発行する許可を取得した後、次回、検証済みブートのバリエーションについて特定のシステムをチェックする方法について説明します。

最初のレベルの攻撃者はリラックスして楽しむことができます-ハードウェア検証に加えて、その後の防御はどれもそれらを防ぐことができません。 だからこそ、私が話をして、これからも言い続けます。ファームウェアの真剣な研究者にとって、プログラマーとSOICクリップは必須です。

2.ハードウェアスイッチを備えた読み取り専用ストレージ

古代のUEFI以前、多くのマザーボードには、偶発的または悪意のあるファームウェアからBIOSチップを保護するジャンパーがありました。 そのような保護の実装に実質的に困難はありませんでした。 すべてのBIOSセットアップの内容はCMOS SRAMに個別に保存され、ファームウェアを更新する場合を除き、単に何も書き込む必要はありませんでした。 その後、Intelの誰かがCMOSに十分なスペースがないと判断したため、チップをより迅速かつ迅速に取り、そこにすべての設定を書き込む必要がありますが、無駄に失われるはずです。 この「邪悪な」ソリューション（および同じレベルの天才の一連のソリューション）の結果として、すべてが1つのチップにあることが判明しました。実際にはUEFI、統合ネットワークカードのファームウェアの一部（ GbE ）、ほとんどのチップセットファームウェア（ ME ）、 ECファームウェア、および地獄は他のものを知っています、およびチップの3人の所有者（CPU、ME、およびGbE）のそれぞれが、更新時だけでなく、通常はいつでもそれに書き込む権利を受け取りました。 発生した混乱を何らかの方法で合理化するために、Intelはチップの先頭にFlash Descriptorを追加しました。これにより、各地域への3人の所有者のアクセス権が明示的に規定されました（記述子と形式については既に説明しました）が、これはあまり役に立ちませんでした。 フライをカツレツとROからRWに分離する唯一の公式サポート方法は、2つのSPIチップをインストールすることです。1つ目はDescriptor、ME、GbE、NVRAMに、2つ目はUEFIの残りに、2つ目のチップの#WPレッグがジャンパーで着地し、保護しますその記録ハードウェアから。

このような保護にはいくつかの問題があります。

-2個のチップは1個の2倍の価格よりわずかに低く、購入者は大量生産で100万または2ドルを節約したいので、2個のチップを搭載したボードは日中見つけることができません。

-ファームウェアには物理アクセスが必要です。 GPIOへの#WP出力は、芽のすべてのセキュリティを破壊します。

-物理的にアクセスしなくても、RWチップの内容を損なうことがあります。

残念ながら、UEFIを使用したマスマーケットシステムでのこのような保護の実装はまだ見ていません。 以前はありましたが、現在はChromebookにのみ残っていますが、ファームウェアはcorebootに基づいています。 ファームウェアに対するハードウェア保護がどのように実装されているかは、他のどこにも同じMEが存在する場合、正確にはわかりません...

3.チップセットのPRレジスタ

SPIマイクロ回路を書き込みから保護できない場合は、チップセットで保護できます。 すべての最新のチップセットには、物理​​メモリブロックの読み取りおよび/または書き込みから保護するために設計された少なくとも4つのPRレジスタがあります。 SPIチップは常に物理メモリの最初の4 GBの「ボトム」にマップされます（つまり、SPIチップの最後のバイトは常に物理アドレス0xFFFFFFFFにあります）が、ファームウェアの全部または一部を保護できます。

この種の保護にも問題がないわけではありません。

-再起動時にレジスタ値もリセットされ、復元する必要があることを忘れずに、正しく実装する必要があります。

-構成のロックをインストール（および再起動後に復元）することを忘れないでください。そうしないと、悪意のあるコードが簡単にリセットできます。

-保護を無効にすることはできません。 再起動せずにOSからファームウェアを更新することはできなくなります。

-そして、もちろん、NVRAMおよびその他のRWエリアはこの方法では保護できません。

前の段落とは異なり、海上市場でPR'amiを使用するシステム、およびほとんどすべての保護は、文盲または不完全で実装されています。

4.1。 SMM_BWPおよびSpiRomProtect

再びIntelとAMDに対する同様の保護。それぞれ、SMMを除き、どのプロセッサモードからでもSPIチップへの書き込みを許可しません。 ファームウェアを更新するには、特別なSMIプロセッサが使用されます。これは、新しいファームウェアの整合性と署名の検証を実行する必要があり、検証が成功した後にのみファームウェアを実行します。

この保護は実装が非常に簡単であるため、ほとんどすべてのUEFIで使用できますが、デフォルトでは無効になっている場合があります。 大きなプラスは、ファームウェアコードがアーキテクチャから独立していることです。

欠点もあります：

-SMMには多くのコードがあり、そこに脆弱性があると、ファームウェアに完全にアクセスできます。

-フラッシャー自体の実装のバグから誰も安全ではありません。

-保護がNVRAMの変数によって制御されている場合（これがそうであるシステムがたくさんあります）、UEFIシェルをロードできる攻撃者によって単純に無効にされる可能性があるため、実質的に役に立ちません。

上記の欠点を見てから、Intelのスタッフはそれらを修正することを決めました。IvyBridgeの周辺のどこかで、次の保護を思い付きました。

4.2。 Intel BIOS Guard、旧PFAT

SMMにコードが多すぎると正しく判断し、 IBVはそれらに穴がないようにフラッシャーを書き込むことができないため、Intelはさらに深くすることを決定し、別の特権実行モード、特別なACRAMメモリ領域を追加しました。他のモードでは、IntelのEDSによって署名されたファームウェアのみをロードでき、SPIチップに記録できるのは彼のみです。 パラグラフ4.1の3つの問題はすべて正常に解決されましたが、同時に、新しい問題も追加されました。

-すべてがうんざりするほど複雑。 独自のDSL上のスクリプト、くしゃみごとの署名、個別のコンポーネントの更新、その他の地獄とホンジュラス。

-更新用のイメージをプログラマーにフラッシュすることはできません。そのようなファームウェアを復元するには、文字通り、断片から組み立てて、常に宣誓する必要があります。

-ベンダーのロックインはもちろんです。

一部の勇敢なメーカーはPFATを使用しており、それでも動作しますが、試してみましたが、私は言うことができます-トリックなしで、私はSMMコードをこれよりも数回監査したいです。

私はPFATに対する攻撃について何も知りませんが、ここでとらえどころのないJoeのルールはおそらく機能します。

5. BLEおよびBIOS_WE

むかしむかし、まだSMM_BWPがなく、プロセッサに1つのコアがあった場合、IntelのSPIチップへの書き込み保護は次のように編成されました。チップセットが書き込みコマンドを送信できるように設定する必要があるBIOS_WEビットがあります。 このビットはどのコードでも使用できるため、その隣にBLEがあります。 インストールされている場合、BIOS_WEインストールはSMIを生成し、BIOSはこのSMIのハンドラーを登録し、BIOS_WE自体をリセットします。 ソフトウェアはビットがリセットされたことを認識し、書き込みの試行を停止します-保護はそれだけです、不可能です。 SMMからフラッシュする場合、BIOS_WEをインストールすると、中断は発生せず（既にSMMにいます）、縫うことができます。

その結果、すべての保護はBIOSがハンドラーを追加し、SMIが生成されるという事実に基づいているため、攻撃が成功するために、忘れられたSmiLockビットはこのSMIのソースを無効にして静かに何かを縫うのに十分でした。 その後、SmiLockは忘却を止め、一部のIBVは、313Rafal WojtczukとCorey Kallenbergでマルチコアプロセッサ上でBLE / BIOS_WEメカニズムが競合状態に対して脆弱であることを示すまで、保護が信頼できると確信していました。 攻撃の所要時間は10分未満で、常に成功します。

それにも関わらず、BLEによってのみかつ排他的に保護されているシステムは、依然として存在します。 これは悲しいです。

6.行方不明

「誰もいないパイ」の教科書の例。 デスクトップマザーボードの一部のメーカーは、指先を指さず、ファームウェアが上書きされないように保護していません。 お使いのシステム-わずらわしいことですが、セキュリティのような錯覚はしません。裸のBIOSのみ、ハードコアのみです。 このように毎日行動することは、一方ではIntelが推奨事項を押しつぶし、他方ではMicrosoftがHSTIを使用しているため、より困難になっていますが、これまでのところ、彼らは対処しています。 勇気の狂気、そしてすべて。

おわりに

ファームウェアに対する保護については多かれ少なかれ理解しました。次のパートでは、SMMとその攻撃について説明します。

ご質問やご意見をお待ちしております。 ご清聴ありがとうございました。