APIC/エピック! Intel チップは、カーネルが見てはならない秘密を漏らします…

これが今週の BWAIN です。 印象的な名前のバグ.

BWAIN は、新しいサイバーセキュリティの欠陥が興味深く重要であることが判明しただけでなく、独自のロゴ、ドメイン名、および Web サイトが見つかった場合に提供する称賛です。

これは吹き替えです ÆPIC リーク、言葉のしゃれ APIC & EPIC.

前者は略して 高度なプログラマブル割り込みコントローラ、後者は単に「叙事詩」という言葉です。 巨大な, 大規模な, 極端な, メガ, 巨大な.

Æ という文字は、サクソン時代以降、英語の書き言葉で使用されていません。 その名前は æsc、発音される 灰 （ツリーのように）、それは現代語の ASH の A の音をほとんど表しています。 しかし、私たちはあなたが単語を発音することになっていると仮定しています エピック ここでは「APIC-slash-EPIC」または「ah!-eh?-PIC」のいずれかです。

一体何のこと？

これらすべてから、次の XNUMX つの魅力的な疑問が生じます。

• APIC とは、そしてなぜそれが必要なのですか？
• どのようにしてデータを取得できますか カーネルでさえ のぞき見できない？
• この壮大な失敗の原因は何ですか APIC で?
• しない ÆPIC リーク 私に影響を与える?
• 何をすべきか それについて？

APIC とは何ですか?

IBM PC が最初に登場した 1981 年に戻りましょう。

PCには、と呼ばれるチップが含まれていました。 Intel 8259A プログラマブル割り込みコントローラ、またはPIC。 (PC AT 以降のモデルでは、より多くの割り込みイベントをサポートするために、チェーン化された XNUMX つの PIC がありました。)

PIC の目的は、文字通り、すぐに注意が必要なタイム クリティカルな何かが発生したときに、PC の中央処理装置 (CPU) で実行されているプログラムを中断することでした。

これらのハードウェア割り込みには、次のようなイベントが含まれていました。 文字を受信するシリアルポート。 繰り返しハードウェア タイマーがカチカチ音をたてます。

この種のハードウェア割り込みシステムがなければ、オペレーティング システムは定期的に受信キーストロークをチェックするための関数呼び出しで散らかる必要があります。これは、誰も入力していないときに CPU パワーを浪費するだけでなく、応答しなくなります。彼らがしたときは十分です。

ご想像のとおり、PIC に続いてすぐに、 APIC、 高度な CPU自体に組み込まれた一種のPIC。

最近の APIC は、キーボード、シリアル ポート、およびシステム タイマーからのフィードバックだけではありません。

APIC イベントは、過熱などのイベントによってトリガーされ (およびリアルタイム データを提供し)、最新のマルチコア プロセッサの異なるコア間のハードウェア相互作用を可能にします。

そして、今日の Intel チップは、非常に簡単に言うと、通常、次の XNUMX つの異なる方法で動作するように構成できます。 xAPIC モード & x2APIC モード.

ここでは、 xAPIC 割り込みコントローラからデータを抽出する「従来の」方法であり、 x2APIC より現代的な方法です。

さらに単純化すると、xAPIC は ミオ、の略 メモリマップ入出力、対象のイベントを登録するときに APIC からデータを読み取るため。

MMIO モードでは、APIC チップ自体の入力/出力レジスタをミラーリングするメモリ (RAM) の特定の領域から読み取ることによって、何が APIC イベントをトリガーしたかを調べることができます。

この xAPIC データは、コンピューターの物理 RAM のどこかにある 4096 バイトのメモリ ブロックにマップされます。

これにより、データへのアクセスが簡素化されますが、APIC チップとシステム メモリの間で面倒で複雑な (そして、後で説明するように、潜在的に危険な) 対話が必要になります。

対照的に、x2APIC では、 APIC データを直接読み取る として知られているものを使用して、チップ自体から モデル固有のレジスタ (MSR)。

Intelによると、プロセスのMMIO部分を回避する 「プロセッサのアドレス指定可能性が大幅に向上し、割り込み配信が強化されました。」

特に、APIC データをオンチップ レジスタから直接抽出するということは、サポートされるデータの合計量と、同時に管理できる CPU コアの最大数が、MMI​​O モードで使用可能な 4096 バイトに制限されないことを意味します。

カーネルでさえ覗き見ることができないデータをどうやって手に入れることができますか?

xAPIC モードを使用しているときに MMIO メモリ領域に格納されるデータが、必ずしも適切に管理されているとは限らないことは、すでにご想像のとおりです。

…したがって、その MMIO 領域へのある種の「データ漏洩」が、この問題の核心です。

しかし、あなたを考えると すでにシステム管理者レベルの権限が必要 最初にMMIOデータを読み取るため、メモリ内のすべてのデータをほぼ確実に取得できます...

…誤って APIC MMIO データ領域に他の人のデータが表示されるのはなぜでしょうか? エピック リーク？

実際には、ある種のデータ盗用や RAM スクレイピング攻撃が少し簡単になるかもしれませんが、理論上すでに持っていたメモリ スヌーピング能力がさらに向上することはないのでしょうか?

残念ながら、システム上のソフトウェアが Intel の SGX を使用している場合、その仮定は正しくありません。 ソフトウェアガード拡張機能.

---

SGXについてもっと知る

---

SGX は最近の多くの Intel CPU でサポートされており、オペレーティング システム カーネルがコードとデータのチャンクを RAM の物理ブロックに「封印」して、いわゆるエンクレーブを形成する方法を提供します。

これにより、少なくとも一時的には、解読キーなどの秘密を保存するために使用される携帯電話の特別なセキュリティ チップと同じように動作します。

エンクレーブの SGX「ロック」が設定されると、封印されたメモリ領域内で実行されているプログラム コードのみがその RAM の内容を読み書きできます。

その結果、エンクレーブがアクティブ化された後に発生する計算の内部詳細は、システム上の他のコード、スレッド、プロセス、またはユーザーには見えません。

カーネル自体を含みます。

エンクレーブに封印されたコードを呼び出す方法と、実行する可能性のある計算の出力を返す方法がありますが、コードを回復したり、スパイしたり、デバッグしたりする方法はありません。実行中の関連データ。

エンクレーブは事実上、秘密鍵で署名されるデータなどの入力をフィードしたり、生成されたデジタル署名などの出力を抽出したりできますが、そこから暗号鍵を取り出すことはできません。署名プロセスで使用されます。

ご想像のとおり、SGX エンクレーブ内に封印されているはずのデータが、xAPIC の「メモリ マップ」モードを使用しているときに、APIC データを「ミラーリング」するために使用される MMIO RAM に誤って複製された場合…

…これは、SGX エンクレーブ内で既に実行されているコードによって意図的にエクスポートされない限り、SGX エンクレーブが作成された後にデータが出現してはならないという SGX のセキュリティに違反します。

APIC でのこの壮大な失敗の原因は何ですか?

背後にいる研究者 ÆPICリークペーパー 狡猾で異常なメモリ アクセス シーケンスを介して APIC データを読み取るように手配することにより、それを発見しました…

…プロセッサをだまして、APIC 自体から新たに受信したデータだけでなく、CPU が他の目的で最近たまたま使用したデータで APIC MMIO スペースを埋めることができます。

この動作は、APIC MMIO メモリ ページのサイズが 4096 バイトであるにもかかわらず、xAPIC モードの APIC チップが実際には 4096 バイト相当のデータを生成せず、CPU が常に正しく中和するとは限らないという事実の副作用です。 MMIO 領域の未使用部分を最初にゼロで埋めます。

代わりに、CPU キャッシュに残った古いデータが、APIC チップ自体から受信した新しいデータと共に書き出されました。

研究者が述べたように、バグは、いわゆる 初期化されていないメモリの読み取り、RAM 内の他の誰かの残りのデータを誤って再利用した場合、最初に以前の秘密をフラッシュしなかったためです。

ÆPIC リークは私に影響を与えますか?

影響を受けるチップの完全なリストについては、 インテル独自のアドバイザリ.

私たちの知る限り、第 10 世代または第 11 世代の Intel プロセッサを使用している場合、おそらく影響を受けます。

しかし、真新しい第 12 世代 CPU (執筆時点で最新のもの) を使用している場合は、サーバー クラスのチップのみが影響を受けるようです。

皮肉なことに、Intel は第 12 世代のラップトップ チップで SGX をあきらめたので、このバグは適用されません。

もちろん、潜在的に脆弱なチップであっても、SGX を使用するソフトウェアに依存していなければ、このバグも当てはまりません。

そして、ダビングされたバグ CVE-2022-21233、ローカルの管理者レベル (ルート) のコンピューターへのアクセス権を既に持っている攻撃者によってのみ悪用される可能性があります。

通常のユーザー APIC MMIO データ ブロックにアクセスできないため、SGX エンクレーブから漏えいした可能性のある機密データは言うまでもなく、そこにあるものをまったく覗く方法がありません。

だから、 ゲスト仮想マシン HyperV、VMWare、VirtualBox などのハイパーバイザーでホスト オペレーティング システムの制御下で実行されている (VM) は、このトリックを使用して他のゲストやホスト自体から秘密を盗むことはほぼ確実にできません。

これは、通常、ゲスト VM がホスト プロセッサ内の実際の APIC 回路にアクセスできないためです。 代わりに、各ゲストは、その VM に固有の独自のシミュレートされた APIC を取得します。

何をするか？

パニックにならないでください。

ラップトップまたはデスクトップ コンピューターでは、古い (または、幸運なことに、真新しい) コンピューターを使用している、またはいずれにせよ SGX に依存していないため、まったく危険にさらされていない可能性があります。

そして、あなたが危険にさらされていたとしても、管理者/ルートとしてあなたのラップトップに侵入する人はおそらく、すでにあなたに問題を引き起こすのに十分な力を持っています.

脆弱なサーバーがあり、運用上のセキュリティの一部として SGX に依存している場合は、インテルのセキュリティ アドバイザリを確認してください。 インテル-SA-00657 保護と緩和に関する情報。

これを書いた研究者によると、 「インテルは、問題を解決するためにマイクロコードと SGX ソフトウェア開発キットのアップデートをリリースしました。」

また、Linux カーネル チームは現在、システムが常に x2APIC を使用するように構成できるようにするパッチに取り組んでいるようです (以前から覚えているように、共有メモリを介して APIC データを送信しません)。また、起動後にシステムが強制的に xAPIC モードに戻されるのを適切に防ぎます。

---