UEFIセキュリティパート4

UEFIセキュリティについては引き続き説明しますが、今回はNVRAMに対する攻撃とそれらに対する保護に焦点を当てます。

信頼性が低く、バッテリーに依存するCMOS SRAMに依存することなく、設定をSPIチップにほぼ永久に保存できるという一見良いアイデアは、UEFI開発者と非常に残酷な冗談を演じ、現在、標準のすべての新しいバージョンのNVRAMはますます増えています松葉杖と小道具、そしてこのプロセスの終わりは見えません。 彼らが松葉杖でバックアップしようとしていることに興味があるなら、この記事はあなたのためです。

伝統的に、何らかの理由で最初の 3つの 部分を読んでいない人は誰でも-私はそれらから始めることをお勧めします、私はカットの下で残りを楽しみにしています。

パート4 NVRAM

マイナス100万のアイデア

正直なところ、設定リポジトリを何世紀にもわたって配置されていたCMOS SRAMからメインチップに転送するというアイデアを誰が思いついたのかはわかりませんが、現時点では、これは鉄の生産者と開発者へのクマサービスであると言えますファームウェア、およびエンドユーザーに。 どうやら、Intelにはいくつかの理由があったため、4つのランタイムサービスGetVariable / GetNextVariableName / QueryVariableInfo / SetVariableで表されるNVRAMへのインターフェイスは、最初に公開されたIntelの一部になりました（UEFIフォーラムの組織がほぼ独占的に機能する前に）標準EFI 1.10、UEFIの現在のすべての実装の先駆者。

NVRAMはどのように機能しますか？

論理的に、NVRAM（UEFI仕様に準拠）は変数のセットであり、各変数にはGUID（必ずしも一意ではない）、名前（UCS2エンコーディング）、属性（以下で説明）、およびこの変数に格納されているデータがあります。

タイプごとに、変数は通常の変数（RAMに保存され、リロード時に値を保存しない）、 NV （割り当てられたSPIチップ領域に保存され、再起動時にそこから読み取られる）およびHR （SPIチップに保存されるが、NV、OSとは別に検出されたハードウェアエラーについてファームウェアに通知するためのUEFIサポート）。

アクセスレベルによって、変数は最初に2つのタイプに分けられました-BS （OSがロードを開始した後は使用不可）とRT （常に使用可能）ですが、UEFI 2.3.1C規格にSecureBootテクノロジーが導入されたため、通常のRT変数にさらに2つの亜種が追加されました-AW（記録用）認証が必要）およびTA （同じですが、リプレイ攻撃から保護するためのタイムスタンプ付き）。

変数のタイプは、その属性によって決まります。 NV + BS + RTは、起動時とOSの両方で読み取りと書き込みが可能なSPIチップに保存されている変数です。 また、標準では変数の処理規則も定義されています。たとえば、RT属性の存在はBSの存在を自動的に暗示し、NV属性のない変数への書き込みはOSから不可能です（そのような変数はすべて、UEFIブートローダーを終了するExitBSイベントの後に読み取り専用になります） 。

上記のインターフェースが唯一のものであり、変数にアクセスするために彼だけが使用される場合、すべてがうまくいくでしょう。 残念ながら、これは完全に真実ではなく、一部のNV変数はHIIドライバーを使用してNVRAMドライバーをほとんどバイパスするため、ユーザーにBIOSセットアップメニューが提供されるため、NV変数の保存形式も標準化する必要があり、NVRAMはSPIチップではなく、どこかに保存されましたそれはまだかなり難しいです。

最も有名なこのようなデュアルアクセス変数はSetupで、BIOSセットアップから変更できる設定のほぼ100％（パスワードといくつかのものを除く）を保存します。 そのフォーマットは、ほぼすべてのバージョンとすべてのシステムで一意ですが、 HIIドライバーは、どの設定がどのオフセットであるかを正確に認識しており、オープンソースユーティリティのペアを使用するファームウェアイメージがある場合、この知識は非常に簡単に抽出されます。これにより、攻撃者にとって潜在的に危険な機会が開かれます。

NVRAMへの攻撃

紳士物忘れ2

なぜなら NV変数を保存するには、SPIチップを使用します。NVRAMの動作には、OSの動作中に書き込む必要があります。これにより、 ROチップまたはPRレジスタの助けを借りてすぐに保護が終了します。 それにもかかわらず、多くのシステムメーカーは依然としてPRレジスタを使用しており、NVRAMが書き込み保護されていないエリアに分類されるように設定していますが、同時に、NVRAM用のSMMドライバーとSMM_BWP / SpiRomProtectビットを設定します。 忘却の結果は、認証を必要とするSecureBoot変数（すぐにテクノロジ全体を完全に役に立たなくする）やセットアップ（ファームウェアの残りの部分の保護を無効にし、再起動後に既にいっぱいになるなど、属性に関係なくすべてのNV変数へのフルアクセスです。 SPIチップのすべてのコンテンツへのアクセス）、一般的なDoSは言うまでもありません。 このような単純な攻撃に対して脆弱なシステムの数は驚くべきものです。たとえば、ほとんどすべてのAcerラップトップはこの方法で「保護」されています。

忘れっぽさのもう1つの例は、セットアップなどの重要な変数のデバッグ用にRTを配置し、この属性を削除するのを忘れることです。 その結果、OSから直接設定を変更できます。非常に便利ですが、SecureBoot全体が無駄になります。

縁を越えて

別の攻撃は、世界で古く、簡単なものです。大きな変数、小さな変数、多くの変数、1つの同じ変数をNVRAMに100回書き込みます。 次に、再起動して反応を確認します。 NVRAMの正しい実装は、不必要なEFI_OUT_OF_RESOURCESリクエストにすべて回答し、リブート後にすべてが機能しますが、NVRAMが崩壊してシステムが上昇し、ロードを続行できない場合、例も結果も異なります。 ほとんどの場合、DoSはこれから取得されますが、攻撃者が本当に必要な場合は、上記を参照してください。

UEFIローダーの逆襲

また、この攻撃はそれほど新しいものではありません。2013年には、優れたポスト同志がいました。 偽時計 攻撃の本質は、ローダー（少なくともGRUB、少なくともUEFI Shell、少なくともUEFIアプリケーションを使用できる）がExitBSイベントが発生する前に任意のコードを実行できることです。 ブートローダーの初期段階では、セットアップを含むBS変数に完全にアクセスできます。 BIOSのセットアップを呼び出すための時間枠が終了した後、プラットフォームの製造元がこの変数への書き込みを禁止しなかった場合（そのような保護は1つの産業用ボードでしか見られませんでした）、ブートローダー（またはブートローダーにシェルがある場合はユーザー） ）Setup変数の内容を読み取って変更できます。5回目は、この危険性については書きません。 このようないブートローダーに対する提案されている保護はSecureBootですが、デフォルトでキーを使用すると、Microsoftを盲目的に信頼することをお勧めします（IBVはシェルでブートローダーに署名しないことを誓いました）、およびデフォルトキーを持つオープンOSの愛好家のために、MSだけでなく、 Canonical、文字通りこの攻撃に対して防御するものはありません-Canonicalキーで署名されたシェルおよびその他のグッズを備えた最新のGRUB2ビルドはUbuntuリポジトリから直接ダウンロードできます。

最後の部分の結論として、BIOSのパスワードは正直な人のものであると述べました。 私は説明します：それは、ほとんどの場合、設定への不正アクセスから、そしてBIOSセットアップインターフェースからアクセス可能なものからのみを保護します。 NVRAM（ Read Universal ）にアクセスするための適切なユーティリティ、UEFIイメージパーサー（ UEFITool 、 PhoenixTool 、 uefi-firmware-parser ）およびIFR（ Universal IFR Extractor ）パーサーを使用すると、非表示の設定を含むすべての設定へのアクセスを整理できます。パスワードをバイパスし、BIOSセットアップで「フェンスの穴」を掘り進むのに飽きたときに、この同じパスワードをリセットします。

社会主義のリモート

最後に、標準のLinux efibootmgrユーティリティが疑いのないBIOSで実行できる最も無害なNVRAM関連の攻撃。 月の位相と宇宙線の強度に応じて、時には核の次の更新で、次の変数BootXXXXを追加するだけでなく、その後いくつかの隣接するものを削除することが判明し、今回の光線が特に高エネルギーである場合-それだけです。 その後、PhoenixまたはInsydeによるUEFI実装の約30％が完全に停止します。結局、BDSフェーズは終了し、起動するものはもうありません。 同時に、BIOSセットアップなどのst迷から抜け出す可能性もすべてBootXXXXの中にあり、ユーザーはCrisis Recoveryサブシステム（RTFMで可能な場合）を使用するか、システムをサービスに持ち込む必要があります。 過去数年にわたって、私は3つの根本的に異なるシステムでこの攻撃に4回遭遇しました。 彼らが言うように、安定性は習熟の兆候です。

最高の防御

逆説的に聞こえるかもしれませんが、NVRAMで起こりうるすべての問題に対する最善の保護は、NVRAMからNVを削除することです。 SPIチップにあるすべての変数をRAMに転送し、BIOSセットアップの直後にPRレジスタを使用してそれらの領域に書き込み保護を設定します（以前に行った場合、設定は保存されなくなります）。 NVRAMの記録を何らかの方法で使用する唯一の最新のOSはMacOS Xですが、SMMとSecureBootを使用しない独自のlunaparkがあるため、それらについては別の議論があります。 WindowsとLinuxは、NV + RT変数が保存されなくなり、インストーラーが問題（ブートローダーをBootXXXXで記述しますが、保存されない、悲しみ）といくつかの非常に特殊なソフトウェア（鼻血が出る）を経験するのに優れています変数が必要ですが、そのようなソフトウェアを見たことはありません）。 OSでの通常の動作も、Capsule Updateメカニズムを使用したファームウェアアップデート（またはその個々のコンポーネント）でも、保護されていないNVRAMの影響はほとんどありません。 最初から必要だったのだろうか...

おわりに

サイクルは徐々に終わりに近づいています。SecureBootに対するいくつかの歴史的な攻撃、署名されていないオプションROMの危険性、そして顕著な問題の多くが発見された顕著な男性（および女性）について語っています。 いくつかの部品で十分です。

読者の皆さんの注意、ファームウェアの成功に感謝します。覚えておいてください。NVRAMは若い年齢から保護する必要があります。