仮想マシン（VM）が別のVMを同じ物理マシンで実行している "ハック"できるか？

Question

質問：

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

警告：

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

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

例：

2年前、 [〜＃〜] mmu [〜＃〜] （他のマシンのメインメモリにアクセスしていると思います）に関連するセキュリティの問題がある可能性があると聞きましたが、私はそうではありませんそれが今日の実用的な脅威なのか、それとも単なる理論的な研究対象なのかを知る。

EDIT：私も見つかりました this "Flush + Reload" attack 対応GnuPGがanotherVMで実行されている場合でも、L3 CPUキャッシュを利用して、同じ物理マシンでGnuPG秘密鍵を取得する方法。それ以来、GnuPGにパッチが適用されています。

Falcon Momot · Accepted Answer

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

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

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

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

とはいえ、上記で説明したベクター（特定のケースで最後のベクターを例外とする可能性がある）は、ベアメタル環境には存在しません。だから、はい、セキュリティはあなたが知っているエクスプロイトが知らないエクスプロイトから保護することであり、一般に公開されていないエクスプロイトと同様に、一般に公開されていないエクスプロイトです。ベアメタルで実行するか、少なくともハイパーバイザーがすべての仮想マシンをホストしない環境で実行することにより、セキュリティが少し向上する可能性があります。

一般に、安全なアプリケーションプログラミングの効果的な戦略は、コンピュータ上で実行されている他のプロセスが攻撃者制御または悪意のあるものであると想定し、そうでなければそのようなプロセスを保証しないと考えている場合でも、悪用を意識したプログラミング手法を使用することです。 VMに存在します。ただし、特に最初の2つのカテゴリでは、ハードウェアに最初に触れた人が勝つことを覚えておいてください。

Michael Hampton · Answer

理論的には違います。ハイパーバイザーの要点は、仮想マシンを互いに分離することです。

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

Ryan Ries · Answer

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

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

珍しい
本質的にデリケートであり、オープンに共有されていません。共有されている場合、このサイトの誰もがエクスプロイトを知る前に、ベンダーがエクスプロイトにパッチを適用します。
複雑で、ベンダーによって異なります

ハイパーバイザーをハッキングして他のVMにアクセスすることは不可能だとは言えません。また、ハイパーバイザーのエクスプロイトを利用した攻撃のストーリーがあまり見られないことを考えると、経験がかなり低いことを除いて、リスクの量を定量化することもできません。

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

ただし、テクノロジーがハイパーバイザに依存するようになった今、このようなエクスプロイトは、他のほとんどのタイプのエクスプロイトよりも緊急にパッチが適用され、防御されます。

以下は、IBM X-Force 2010中間年トレンドおよびリスクレポートからの抜粋です。

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

IBM X-Force 2010 Mid-Year Trend and Risk Report.

「Escape to hypervisor」脆弱性の測定されたパーセンテージに注意してください。これは私にはかなり恐ろしく聞こえます。当然のことながら、クレームをバックアップするためのレポートにはさらに多くのデータが含まれているため、レポートの残りの部分を読む必要があります。

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

ここは、VMwareのEric Horschmanによる素晴らしい記事で、ティーンエイジャーが反Micro $ oftを完全に使用しているように聞こえますが、それでも良い記事です。この記事では、次のようなヒントを見つけます。

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

競争相手の間でおかしい。しかし、おそらく彼が記事全体で言っている最も明快なことはこれです：

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

user62491 · Answer

OpenBSDプロジェクトのこれまでにない Theo de Raddt ：

セキュリティホールのないオペレーティングシステムやアプリケーションを書くことができない世界中のソフトウェアエンジニアが、セキュリティホールのない仮想化レイヤーを急いで書き直すことができると考えるなら、あなたはまったく愚かではありません。

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

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