スペクターセキュリティの脆弱性は仮想マシンに存在しますか？

VirtualBoxのような仮想マシンにセキュリティ脆弱性「spectre」がある可能性はありますか？VMはアウトオブオーダーの実行を行う可能性があると思いますが、私の意見では、キャッシュを覗いて結果を読み取ることはできません。

仮想CPUのキャッシュを読み取る方法はありますか？

はい、VMWareがSpectreおよびMeltdownに対処するパッチをリリースしたことを確認した研究が少しありました。ゲストOSは、実際のハイパーバイザー（両方のタイプ）に、加えて、パッチを適用する必要があります

— Ramhound

仮想化のレベルに依存します。仮想CPUをシミュレートしている場合、おそらく安全です。しかし、それは現代のVMが行うことではありません。

— ベルギ

仮想CPUのキャッシュを読み取る方法はありますか？

@jmsの詳細は、私は私の答えにリンクされ標準的なポストである：

Spectre works on a different level ... In this attack, the attacker tricks the speculative execution to predictively execute instructions erroneously. In a nutshell, the predictor is coerced to predict a specific branch result that results in asking for an out-of-bound memory access that the victim process would not normally have requested resulting in incorrect speculative execution. Then by the side-channel, retrieves the value of this memory. In this way memory belonging to the victim process is leaked to the malicious process.

— Mokubai

@jms仮想化は、できるだけ抽象化されていない物理CPUを使用し、分離と抽象化を提供するためにCPUハードウェアに依存するため、高速です。以下のようなものがqemuそうではないとして、より安全になりエミュレーションを行うことができ、ハードウェアの CPUが、それは非常に遅いと仮想化は異なっているが。

— 木梅

はい。Specterはホスト/ゲスト、ゲスト/ホスト、ゲスト/ゲストの境界を越えることができます。これはCPUレベルの欠陥であり、潜在的に機密情報がCPUコアで実行されるあらゆるものに漏洩する可能性があるためです。

インターネット上のニュース記事のほとんどは、クラウドプロバイダーが仮想化されたシステムの大規模なクラスターを有し、機密情報を漏らすために悪用される可能性があるため、これにより最悪の打撃を受けていることについて語っています。

大規模なプロバイダーのほとんどは、できる限り最善の方法で欠陥に対してパッチを適用する必要がありますが、これはしばらくの間私たちと一緒に生きる問題になるでしょう。

Security.SEには、これに関する標準的なQ＆Aがあり、VMについて言及しています。

仮想マシン/コンテナを実行していますが、どの程度まで脆弱ですか？

あたりとしてステファン・ウルリッヒの答え

メルトダウン攻撃はVMを通過せず、カーネルメモリをローカルプロセスにリークするだけです。

SpectreはVM間で機能します。

また、Steffenから、MeltdownとSpectreはコンテナで動作します。コンテナはホストカーネルに依存しているためです。

VMは、システム内の実際のCPUを使用しますが、一部の特権命令はトラップされ、リダイレクトされます。ホストと同じキャッシュと命令を使用します。基本的には、システムの物理CPU内の別のレイヤーです。

仮想化は、できるだけ抽象化せずに物理CPUを使用し、CPUハードウェアに依存して分離を提供するため、高速です。qemuのようなものは、ハードウェアCPUではないため安全なエミュレーションを実行できますが、はるかに遅く、仮想化とは異なります。

Security.se正規のポスト再び：

スペクターは異なるレベルで動作し、ユーザー空間からカーネル空間データへのアクセスを許可しません。この攻撃では、攻撃者は投機的実行をだまして、命令を誤って誤って実行します。一言で言えば、予測子は特定の分岐結果を予測するように強制され（-> trueの場合）、犠牲プロセスが通常は要求しなかった範囲外のメモリアクセスを要求し、不正な投機的実行をもたらします。次に、サイドチャネルで、このメモリの値を取得します。このようにして、被害者プロセスに属するメモリが悪意のあるプロセスにリークされます。

そのため、VMは実際のCPUハードウェアで実行され、必要なのは特定のループを実行して投機的実行エンジンを「トレーニング」するだけです。次に、正確なタイミングを使用して、悪用しようとしているホストまたはゲスト（または他のVM）プロセスを示す特定のアクセスパターンのキャッシュを監視します。

このように、それはマシンがあらゆる方向で悪用可能であることを意味します。ホストからVM、VMからホスト、VMからVM。

はい、それは決して簡単ではなく、ホストの気まぐれでVM CPUコアが変更され、ホストも異なるコアでタスクを喜んでスケジュールすることができますが、長期間にわたって十分な情報いくつかの重要なシステムまたはアカウントへの秘密鍵を放棄するために漏洩する可能性があります。十分な時間と適切にステルスなソフトウェアを考えると、すべてが潜在的にオープンです。

「安全な」VMが必要な場合は、コアが分離されていることを保証する必要があります。この攻撃をブロックする唯一の本当の方法は、ホストとVMが特定のコアのみを使用するように「強制」することであり、同じハードウェアで実行されることはありませんが、これはできないため、コストの効果的な増加につながります特定のホストに同じ数のVMがあります。使用可能なコアよりも多くのVMを実行することで逃げることはできません。これは、多くのシステムがその90％の期間アイドル状態にあるため、「低負荷」サーバーで行われることです。

— モクバイ
ソース

「ホストCPUが影響を受ける場合、VMも影響を受けますか？」と質問を解釈したと思います。私は質問を理解しているので、「ホストCPUに影響がない場合でも、VMに影響を与えることはできますか？」と尋ねます。それをクリアしてもらえますか？

— アンドレKR

@AndreKR：現在、すべてのアウトオブオーダー実行CPUはSpectreの影響を受けています。ソフトウェアの回避策を使用する場合にのみ、システムを安全なものにすることができます（したがって、VMはこれに注意する必要があります。しかし、投機的実行のない順序付けられたCPUでは、2つのソフトウェア間にSpecterの脆弱性は存在しません。Spectreの本質は、秘密データをマイクロアーキテクチャー状態にする何かの投機的実行を引き起こしています。順番どおりのCPUはそうではありません。

— ピーター

最も興味深いのは、投機的実行ではありません。最も興味深いのは、プロセスがキャッシュ内（VM内であっても）を見つける方法です。

@jmsの利用可能なサイドチャネル攻撃は、投機的実行によって促進され、有用になります。プロセスはキャッシュラインを直接読み取ることができない場合がありますが、投機的実行は、タイミング攻撃によって検出または推測できる値をキャッシュに入れる計算を行うことにより、情報をリークする可能性があります。亡霊ホワイトペーパーの第4章では、良い説明があります。spectreattack.com/spectre.pdf

— Mokubai

gem5

ホストCPUを使用せずに、純粋にエミュレーションで脆弱性を調査/再現することに興味がある場合、CPUパイプラインをシミュレートしないため、QEMUがそれらを観察するほど詳細ではないと思います。

ただし、gem5は、研究開発におけるシステムパフォーマンスの推定に使用され、完全にクリーンで制御された環境でSpectreを観察するのに十分なCPU内部をシミュレートします。

視覚化を備えたクールなx86_64デモが次のサイトで公開されています：http : //www.lowepower.com/jason/visualizing-spectre-with-gem5.html

gem5の欠点は、QEMUよりもはるかに遅いことです。シミュレーションがより詳細になります。

— Ciro Santilli新疆改造中心法轮功六四事件
ソース