web-dev-qa-db-ja.com

新しいMDS攻撃とは何ですか？どのようにして軽減できますか？

MDS攻撃 と呼ばれるいくつかの新しいハードウェアサイドチャネルが発見されました。これにより、Meltdownなどの任意のメモリを読み取ることができます。多くの既存の緩和策はそれらに対して役に立たない。関連するCVEは次のとおりです。

  • CVE-2018-12126-マイクロアーキテクチャーストアバッファーデータサンプリング（MSBDS）
  • CVE-2018-12130-マイクロアーキテクチャーのフィルバッファーデータサンプリング（MFBDS）
  • CVE-2018-12127-マイクロアーキテクチャロードポートデータサンプリング（MLPDS）
  • CVE-2019-11091-Microarchitectural Data Sampling Uncacheable Memory（MDSUM）

CPUFail 、 Linuxドキュメント 、および RedHatブログ投稿 について、もう少し情報が提供されています。

私の現在の理解では、マイクロコードの更新により、廃止されたVERW命令の動作が変更され、さまざまな内部プロセッサバッファーがフラッシュされ、ソフトウェアの更新（ Linux で少なくとも） ）は、OSにこの命令をコンテキストスイッチ（たとえば、syscallの開始と終了）で発行させます。ただし、CVE-2018-12130（MFBDS）は、バッファーが論理コア（物理コアではない）間で共有されるため、この方法では軽減できません。 SMT（ハイパースレッディング）を無効にする必要があります。

詳細なブログ投稿 によると、CVE-2018-12130（MFBDS）は、SMTを無効にすることによって部分的にのみ軽減できます。一部の情報は、syscall中のコンテキストスイッチを介してリークされる可能性があります。上記のマイクロコードとソフトウェアの更新は、SMTを無効にすることに加えて、完全に回避するのに十分ですか？

最後に、最新のマイクロコードとオペレーティングシステムの更新をインストールし、SMTを無効にして完全にZombieLoadを含むこれらの新しく発見されたマイクロアーキテクチャ攻撃をすべて軽減していますか？

hardwarethreat-mitigationside-channelintel
10
forest

私の現在の理解では、マイクロコードの更新により、廃止されたVERW命令の動作が変更され、さまざまな内部プロセッサーバッファーがフラッシュされます。

VERW命令の新しい動作は this の記事で説明されています。特に：

  • VERW命令は同じ既存の機能を保持します。つまり、指定されたセグメントが現在の特権レベルから書き込み可能かどうかを確認します。
  • 命令のメモリオペランドバリアントのみが、MDSによって利用されるバッファを上書きすることが保証されています。 register-operandバリアントは、バッファ上書き機能を実行する場合と実行しない場合があります。
  • バッファの上書き機能は、セグメントの書き込み許可チェックの結果（例外を含む）に関係なく発生します。

VERW命令を単独で実行しても、MDSの影響を受けるすべてのバッファが上書きされる前に、後続の命令が実行されるのを防ぐことはできません。したがって、VERWの後にシリアル化命令（Intelが推測バリアを呼び出す）を配置する必要があります。同じ記事の例を考えてみましょう：

Code region A (victim accessing secret data)
VERW m16
Code region B (victim accessing data that is not secret)
Speculation barrier (for example, LFENCE)
Code region C (attacker can only see the data accessed in B)

これらの命令は、MD_CLEARマイクロコード更新（以下で説明）を備えたプロセッサーで実行されていると想定します。 Aの実行により、同じ物理コア上にいくつかの秘密の機内データが残る場合があります。 VERWが実行を開始すると、すべてのリークバッファーが上書きされる前にBが実行される場合があります。 Cが秘密データにアクセスできないようにするには、LFENCEなどのバリアをBの後に配置する必要があります。

VERW命令は、リアルモードおよび仮想8086モードではサポートされていません。これらのモードでは、セグメントアクセス許可を使用できないためです。したがって、これらのモードでは、マイクロアーキテクチャに依存する一連の命令を代わりに使用する必要があります。

VERWの次の特性は、インテルがその命令に（他の命令の代わりに、または新しいMSRを導入する代わりに）バッファ上書き機能でオーバーロードすることを選択した理由を説明しています。

  • VERWはマイクロコード化されており、マイクロコードの更新を機能させるためにおそらく必要です。
  • VERWはめったに使用されないため、結果として生じるパフォーマンスのオーバーヘッドは、既存のソフトウェアではほとんど意味がありません。
  • VERWは、任意の特権レベルで実行できます。特に、セキュリティ境界がユーザーモードの場合（SGXやサンドボックスなど）に使用できます。

VERWは完璧ではありません。上ですでに述べたように、それはリアルモードと仮想8086モードでは機能しません。また、ZFフラグを変更します。

詳細なブログ投稿によれば、CVE-2018-12130（MFBDS）は、SMTを無効にすることによって部分的にのみ軽減できます。一部の情報は、syscall中のコンテキストスイッチを介してリークされる可能性があります。

個別に検討する必要がある2つのケースがあります。

  • 攻撃者と被害者は、同じ物理コアの2つのスレッドで同時に実行することはありません。これは、HTが無効になっている場合、またはOSスケジューラが異なる物理コアで同時にスレッドを実行することを決定した場合に発生する可能性があります（たとえば、スレッドには異なる物理コアアフィニティがあるため）。どちらの方法でも、スレッドは異なる時点で同じ論理コアで実行されます。 MDSエクスプロイトは依然として成功する可能性があります。攻撃者が被害者が実行している論理コアと同じ論理コアで実行する唯一の方法は、被害者がカーネルモード（システムコールやハードウェア割り込みなど）に切り替え、攻撃者が次に同じ論理コアで実行するようにスケジュールされている場合です。 。したがって、カーネルは、ユーザーモードに戻る前にVERW命令を実行することで、攻撃者が内部CPUバッファーを悪用するのを完全に防ぐことができます（その論理コアでスケジュールされているスレッドを次に実行するため）。これにより、ユーザーモードに戻ったときに、バッファーにカーネルからのメモリ要求が含まれないことも保証されます。同様に、VERWは、同じ論理コア上の2つの仮想マシンを切り替えるときに実行する必要があります。
  • 攻撃者と被害者は、同じ物理コアで同時に実行される可能性があります。 Linuxカーネル documentation はMDSで、この特定の状況が最初に発生しないように完全に保護するには、HTを無効にする必要があると述べています。ただし、MDSのIntel article は、グループスケジューリングと呼ばれる代替の緩和策を提案しています。ここでの考え方は、2つのスレッドが相互に信頼し合う場合にのみ、2つの兄弟論理コア上で実行されるようにスケジュールすることです。 Hyper-Vハイパーバイザーはすでにグループスケジューリングを採用しています（そして最近 pdated で、異なるVMに属する仮想プロセッサー間で切り替えるときにVERWを使用します）。 VERW（または代替ソフトウェアシーケンス）の実行中、すべてのバッファーが確実に取得されるように、兄弟の論理コアを静止する必要があります（たとえば、HLTまたはPAUSEを実行）。上書き。

前述の軽減策（カーネルから戻るとき、またはVM間の切り替え、HTの無効化、およびグループスケジューリングのときにMDSの影響を受けるバッファーを上書き）は、特権レベル間の切り替えがないサンドボックスアプリケーション（Webブラウザー内）とSGXエンクレーブを保護できません。 。サンドボックス化されたアプリの1つの可能な緩和策は、代わりにプロセスを使用することです。 SGXエンクレーブは、マイクロコード更新自体によって保護されています。

MD_CLEARマイクロコードの更新には、次の変更が含まれているようです。

  • 上記のVERW命令の新機能。特定の各プロセッサで脆弱なバッファのみが上書きされるため、VERWのパフォーマンスへの影響はプロセッサによって異なります。 MDS攻撃に対して脆弱ではないプロセッサー（第2世代Xeon SPなど）では、VERWはバッファーを上書きせず、通常どおりに動作します。
  • SGXエンクレーブに出入りするとき、MDSの影響を受けるバッファーは上書きされます。ただし、エンクレーブへの入り口では、兄弟の論理コアで信頼できないスレッドが実行されないようにする必要があります。
  • （RSM命令を使用して）システム管理モードを終了すると、MDSの影響を受けるバッファーが上書きされます。ただし、SMMモードに入るときに、SMMソフトウェアは、兄弟論理コアで信頼できないスレッドが実行されないようにする必要があります。
  • セクションIXのRIDL paper は、「更新されたマイクロコードは、L1キャッシュをフラッシュするときに、これらのバッファーもフラッシュする」と述べています。これはIA32_FLUSH_CMD MSRを参照していると思います。インデックス0のビットを1に設定すると、プロセッサが書き戻しを行い、L1Dキャッシュ全体を無効にします。これはL1D_FLUSHコマンドと呼ばれます。また、MDSに対して脆弱なすべてのバッファを上書きします。

this Intelの記事で、マイクロコードの更新とOSパッチ（VERW命令を使用するため）のパフォーマンスへの影響は、一部のベンチマークでは重要（5％以上）であるように見えます。最後に、インテルがHTを無効にしないことを推奨するFAQのリストもあります。

RIDLペーパーのセクションEは、著者がMMU（ページウォークがLFBを通過する）のページウォーキングハードウェアから物理アドレスをリークできたと述べています。軽減策の提案は見ていません。この攻撃のために。

最近の一部のプロセッサには、4つのMDS攻撃すべてに対するハードウェア緩和策が含まれています。これは、次の一連のコマンドを使用して確認できます。

Sudo modprobe msr
Sudo rdmsr -p 0 0x10A

最初のコマンドはmsrカーネルモジュールをロードし、2番目のコマンドはIA32_Arch_CAPABILITIES MSRの値を読み取ります。 6番目のビット（インデックス5のビット）が1の場合、プロセッサにはすべてのMDS攻撃に対するハードウェア緩和策があるため、上記の緩和策のすべては必要ありません。このビットはMDS_NOと呼ばれます。それ以外の場合、プロセッサには、少なくともMSBDS、MLPDS、およびMDSUMに対するハードウェアの緩和策はありません。 IA32_Arch_CAPABILITIES MSR自体がサポートされていない場合、プロセッサはすべてのMDS攻撃に対してハードウェアによる緩和策を確実に備えていないことに注意してください。

MFBDS、MLPDS、およびMDSUMがどのように機能するかについては、次を参照してください。 RIDLの脆弱性とロードの「再生」について MSBDSのしくみについては、次を参照してください： MSBDS（フォールアウト）の背後にあるマイクロアーキテクチャの詳細は何ですか？ 。

6
Hadi Brais

これらはCVEの説明です：

CVE-2018-12126-プロセッサストアバッファーからの情報漏えいにつながる可能性のある問題。

CVE-2018-12127-CPUレジスターおよびCPUパイプラインでの操作に関するデータを攻撃者に提供する可能性があるマイクロプロセッサーロード操作の悪用。

CVE-2018-12130-バッファー内のデータを公開する可能性のあるマイクロプロセッサーフィルバッファーの実装エラー。

CVE-2019-11091-「フィルバッファー」の実装の欠陥。L1CPUキャッシュでキャッシュミスが発生したときに最新のCPUで使用されるメカニズム。

全体的な問題を修正するには、信頼できるコードと信頼できないコードが物理コアを共有しないようにする必要があります。

HTを無効にすると、これがHTのケースで発生しないようにしますが、VM環境では、2つの可能な攻撃ベクトルがあるため、同じ物理コアで危険なコードと危険でないコードが実行される可能性があります。ハイパーバイザーレベル：

シーケンシャルコンテキスト攻撃ベクトル（SCAV、Inter-VM）：悪意のあるVMは、前のコンテキスト（HVスレッドまたはその他のVMの最近アクセスされたデータを推測する可能性があります_スレッド）プロセッサコアのいずれかの論理プロセッサ上。

同時コンテキスト攻撃ベクトル（CCAV Inter-VM）：悪意のあるVMが、同時に実行されているコンテキスト（HVスレッドまたはその他のVMの最近アクセスされたデータを推測する可能性がある） _スレッド）HT対応のプロセッサコアの他の論理プロセッサ上。

ご覧のとおり、ベクトルの1つではHTを有効にする必要はありません。したがって、HTを無効にすると、2つの攻撃の可能性（CCAV）の1つだけが解決されます。

他の問題を修正するには、ソフトウェアレベルのパッチを適用して、SCAVが発生しないようにする必要があります。

[〜＃〜] scav [〜＃〜]の場合、ハイパーバイザーにIntel提供のマイクロコードアップデートをパッチする必要があります。 VMWareの場合、影響を受けるほとんどのIntelプラットフォーム用の個別のESXiパッチで提供されます。 [〜＃〜] ccav [〜＃〜]の場合、VMwareもソリューションを提供します（サイドチャネル対応のスケジューラーを有効にできます-これにより、このような悪用が発生しないことが確実になります）。パフォーマンスに影響を与えます。とにかく、パフォーマンスへの影響はHTを無効にするよりも低くなければなりませんが、SCASは仮想マシンレイヤーではなくハイパーバイザーレイヤー用であることに注意してください。パッチを適用しない場合、実際のVMは依然として脆弱です。

結論として、両方のHVとVMにパッチを適用するか、2番目のケース（CCAV）ではHTを無効にする必要があり、最初のケース（SCAV）ではIntelマイクロコードの更新に基づくHVレベルでのパッチ適用が必要です。

0
Overmind