仮想マシン（VM）は、同じ物理マシンで実行されている別のVMを「ハッキング」できますか？

質問：

• VMが破損（ハッキング）した場合、同じ物理マシン上で実行されている他のVMで何が危険になりますか？
• 同じ物理ホストで実行されているVM間には、どのようなセキュリティ上の問題がありますか？
• それらの（潜在的な）弱点や問題のリストはありますか（作成できますか）？

警告：

多くの仮想化のタイプ/ソリューションが存在し、さまざまな弱点があることを知っています。ただし、特定のベンダーのバグではなく、仮想化技術に関する一般的なセキュリティ問題を主に探しています。

実際の事実、（深刻な）研究、経験した問題、技術的な説明を提供してください。具体的に。意見を述べないでください。

• 例：

2年前、MMU（他のマシンのメインメモリへのアクセス、私は思う）に関連するセキュリティ問題があるかもしれないと聞いたことがありますが、それが今日の実用的な脅威であるのか、単に理論的な研究であるのかわかりません件名。

編集： GnuPGが別の VMで実行されている場合でも、L3 CPUキャッシュを悪用することにより、同じ物理マシンでGnuPG秘密鍵を取得できる「Flush + Reload」攻撃も見つかりました。GnuPGにはパッチが適用されています。

もちろん、同じハードウェア上で実行されている別のVMを悪用することも可能です。さらに、1つ存在することができます。あなたの質問は、最近の研究で示したものを引用しています。ここでは特定のエクスプロイトやPoCを共有するつもりはありませんが、喜んでそれらを作成する方法を説明します。

このコンテキストで使用されるエクスプロイトは、サービスを悪用しようとしているのと同じマシンで実行しているときに機能するエクスプロイトとは当然異なり、分離が増加するため、かなり難しくなる傾向があります。ただし、このような悪用を達成するために使用できる一般的なアプローチには次のものがあります。

• ハイパーバイザーを攻撃します。VMが指定されたハイパーバイザーで十分な特権を持つシェルを取得できれば、システム上の任意のVMを制御できます。これにアプローチする方法は、VMからハイパーバイザーへのデータフローを探し、ハイパーバイザーに大きく依存することです。準仮想化ドライバー、クリップボード共有、ディスプレイ出力、ネットワークトラフィックなどがこのタイプのチャネルを作成する傾向があります。たとえば、準仮想化ネットワークデバイスへの悪意のある呼び出しにより、そのトラフィックを物理NICドライバーに渡す責任があるハイパーバイザーコンテキストで任意のコードが実行される可能性があります。
• ホストのハードウェアを攻撃します。多くのデバイスはファームウェアの更新を許可しており、VMからそのメカニズムにアクセスできるようになった場合は、意図に合った新しいファームウェアをアップロードできます。たとえば、NICのファームウェアの更新が許可されている場合、1つのMACアドレス（被害者の）に向かうトラフィックを別の宛先MACアドレス（あなたの）に複製させることができます。このため、多くのハイパーバイザーは、可能な場合にそのようなコマンドをフィルタリングします。ESXiは、VMから発信されたCPUマイクロコードの更新をフィルタリングします。
• ホストのアーキテクチャを攻撃する。あなたが引用した攻撃は、本質的にはもう1つのタイミングベースのキー開示攻撃です。これは、キャッシュメカニズムの操作タイミングへの影響を悪用して、操作中に被害者VMによって使用されているデータを識別します。仮想化の中核にあるのは、コンポーネントの共有です。コンポーネントが共有されている場合、サイドチャネルが存在する可能性があります。被害者のVMのコンテキストで実行中に、同じホスト上の別のVMがハードウェアの動作に影響を与えることができる限り、被害者のVMは攻撃者によって制御されます。参照された攻撃は、CPUキャッシュの動作を制御するVMの機能（本質的に共有されたユニバーサル状態）を利用して、被害者のメモリアクセス時間がより正確にアクセスしているデータを明らかにするようにします。共有グローバル状態が存在する場所 開示の可能性もあります。仮説に踏み込んで例を挙げると、ESXiのVMFSをマッサージし、仮想ボリュームの一部に同じ物理ディスクアドレスを参照させる攻撃、または実際にメモリを共有すべきであるとメモリバルーニングシステムに信じさせる攻撃を想像してくださいプライベート（これは解放後使用または二重割り当てのエクスプロイトがどのように機能するかに非常に似ています）。ハイパーバイザーが無視するがアクセスを許可する仮想CPU MSR（モデル固有のレジスター）を考えます。これは、VM間でデータを渡すために使用でき、ハイパーバイザーが提供するはずの分離を壊します。仮想ディスクの重複コンポーネントが一度だけ保存されるように圧縮が使用される可能性も考慮してください-攻撃者が独自に書き込み、監視することで他の仮想ディスクの内容を識別することができる構成では、（非常に難しい）サイドチャネルが存在する場合がありますハイパーバイザーが行うこと。もちろん、ハイパーバイザーはこれを防ぐはずであり、仮想的な例は重大なセキュリティバグになりますが、時にはこれらがすり抜けます。
• 他のVMを直接攻撃します。被害者のVMの近くにホストがある場合、ホストの構成方法とアクセス制御を展開するときに行われる仮定に応じて、緩和されたアクセス制御または意図的なVM間通信を利用できる場合があります。これはわずかに関連性がありますが、言及する必要があります。

特定の攻撃が発生し、時間が経つにつれてパッチが適用されるため、特定のメカニズムを悪用可能、ラボ条件でのみ悪用可能、または悪用不能として分類することは決して有効ではありません。ご覧のとおり、攻撃は複雑で困難な傾向がありますが、特定の時点で実行可能な攻撃は急速に変化するものであり、準備が必要です。

とはいえ、上記のベクトル（特定の場合には最後のベクトルを除く）は、ベアメタル環境には存在しません。はい、セキュリティはあなたが知らないエクスプロイトから保護することであり、公開されていないエクスプロイトから保護されていることを考えると、ベアメタルまたは少なくとも、ハイパーバイザーがすべてのVMをホストしていない環境やその他の環境では。

一般に、セキュリティで保護されたアプリケーションプログラミングの効果的な戦略は、コンピューターで実行されている他のプロセスが攻撃者によって制御されているか、悪意がある可能性があると想定し、そのようなプロセスがないことを保証していると考えても、エクスプロイトを認識したプログラミング手法を使用することですVMに存在します。ただし、特に最初の2つのカテゴリでは、最初にハードウェアに触れた人が勝者になることに注意してください。

理論的には、ありません。ハイパーバイザーの重要なポイントは、仮想マシンを相互に分離することです。

実際には、さまざまなハイパーバイザーに1つの仮想マシンが同じホスト上のハイパーバイザーまたは他の仮想マシンに影響を与える可能性のあるセキュリティバグがありました（将来もある可能性があります）。sVirt（KVM / QEMU用）などのセキュリティ対策は、この問題を解決することを目的としています。

編集：このトピックは数か月前に行われたと思っていましたが、復活したばかりで、OPはより多くの「実際の事実、引用された研究」などを求めているので、一体何がわかったのです。

この性質の悪用は次のとおりです。

1. 珍しい
2. 本質的に機密であるため、オープンに共有されておらず、それらが公開されている場合、このサイトの誰もがそれらを知る前に、ベンダーによってエクスプロイトにパッチが適用されます
3. 複雑で、ベンダーによって異なります

ハイパーバイザーをハックして他のVMにアクセスすることは不可能だとは言えません。また、ハイパーバイザーのエクスプロイトを利用した攻撃のストーリーがあまりないことを考えると、そのリスクが非常に低いことを示すことを除き、リスクの程度を定量化することもできません。

これは、ハイパーバイザーベースの攻撃がいくつか実行されたことを示唆する、逆の興味深い記事です。

ただし、現在、ハイパーバイザーに依存するテクノロジーがこれまで以上に増えているため、このようなエクスプロイトは、他のほとんどのタイプのエクスプロイトよりも緊急にパッチが適用され、保護されます。

IBM X-Force 2010 Mid-Year Trend and Risk Reportからの抜粋です。

（この画像を新しいタブで開いて、フルサイズで表示してください。）

「ハイパーバイザーへのエスケープ」脆弱性の測定された割合に注目してください。当然ながら、クレームをバックアップするためのデータがはるかに多いため、レポートの残りの部分を読みたいと思うでしょう。

以下は、Playstation 3ハイパーバイザーで実行される可能性のある悪用に関するストーリーです。あなたのビジネスがソニーでない限り、あなたのビジネスにそれほど影響を与えないかもしれません。その場合、それは非常にインパクトがあります。

ここで彼は一種の私はしばしばフル抗マイクロ$を行くティーンエイジャーのように聞こえるに外れているVMware社のエリック・Horschmanからの素晴らしい記事では、ですが、それはまだ良い記事です。この記事では、次のような情報を紹介します。

Microsoftのガラスの家の住人たちは、私たちのやり方を捨てる他の石を持っていました。Microsoftは、ESXおよびESXiのゲストブレイクアウト脆弱性の例としてCVE-2009-1244を指摘しました。ゲストブレイクアウトのエクスプロイトは深刻なビジネスですが、再度、マイクロソフトは事実を偽って伝えています。VMwareは迅速に対応し、当社製品の脆弱性にパッチを当てました。ESXはMicrosoftがあなたに信じさせるほどの影響は受けませんでした。

競合他社の間でのぐらつき。しかし、おそらく彼が記事全体で言っている最も明快なことはこれです：

真実は、脆弱性とエクスプロイトがエンタープライズソフトウェアにとって完全になくなることは決してないということです。

OpenBSDプロジェクトの今までにない割当可能な Theo de Raddt：

セキュリティホールのないオペレーティングシステムやアプリケーションを書くことができないソフトウェアエンジニアの世界的なコレクションが、セキュリティホールのない仮想化レイヤーを急に書き直すことができると考えると、愚かではないとしても絶対に惑わされます。

少し炎症を起こしますが、彼の主張はよく理解されています。理論的には、仮想化は仮想マシンとそのホストを完全に分離することになっています。実際には、高度な攻撃者がこれらの保護を迂回して他の仮想マシンにアクセスしたり、ホストをさらに悪化させたりすることを可能にするセキュリティ上の脆弱性が時々あります（悪意のある仮想化環境のホストへのセキュリティエクスポージャーに関する実証研究を参照）。Ryan Riesが述べているように、これらの種類の脆弱性は非常にまれであり（存在しないことを意味するわけではありません）、多くの場合ベンダーによって開示されませんが、存在します。

これらの種類の攻撃の可能性を懸念している場合（ある程度はそうすべきだと思います）、単一の仮想ホストまたは仮想ホストクラスターでセキュリティゾーンを混在させないことをお勧めします。たとえば、DMZ仮想マシン専用の2ホスト仮想ホストクラスター、ミドルウェア専用のクラスター、および保護されたアセット用の専用クラスターがあります。このようにして、攻撃者が他の仮想マシンを破壊したり、セキュリティモデルがまだ損なわれていないハイパーバイザー自体を破壊したりするような方法で脆弱性が悪用された場合。