Google Project Zeroチームの研究者は、数日前にブログ投稿で次のように開示しました。 KVMハイパーバイザーの脆弱性（CVE-2021-29657）を特定しました （x86、ARM、PowerPC、およびS / 390でハードウェアアクセラレーションによる仮想化をサポートするオープンソースのLinuxベースのハイパーバイザー） ゲストシステムの分離を回避できます ホスト環境側でコードを実行します。
投稿は、問題が Linuxカーネル5.10-rc1からv5.12-rc6へのマニフェスト、 つまり、 カーネル5.10および5.11のみをカバー （ディストリビューションの安定したブランチのほとんどは、問題の影響を受けませんでした。） この問題は、AMD SVM（Secure Virtual Machine）拡張機能を使用して実装され、ゲストシステムのネストされた起動を可能にするnested_svm_vmrunメカニズムに存在します。
このブログ投稿では、AMD固有のKVMコードの脆弱性について説明し、このバグが完全な仮想マシンエスケープにどのように変わるかについて説明します。 私の知る限り、これはQEMUのようなユーザースペースコンポーネントのバグに依存しないKVMゲストからホストへのブレイクアウトの最初の公開記事です。
議論されたバグはCVE-2021-29657に割り当てられ、カーネルバージョンv5.10-rc1からv5.12-rc6に影響を及ぼし、2021年5.10月下旬にパッチが適用されました。 バグはv5でのみ悪用可能になり、約XNUMXか月後に発見されたため、ほとんどの実際のKVMデプロイメントは影響を受けないはずです。 この問題は、KVMに対して安定したゲストからホストへのエスケープを構築するために必要な作業における興味深いケーススタディであると今でも考えています。この記事で、ハイパーバイザーの侵害が単なる理論上の問題ではないことを証明できることを願っています。
研究者は、この機能を正しく実装するために、 ハイパーバイザーはすべてのSVM命令をインターセプトする必要があります ゲストシステムで実行し、 その動作をエミュレートし、状態をハードウェアと同期します。 これは非常に難しい作業です。
提案されたKVM実装を分析した後、研究者はsMSRのコンテンツを許可する論理エラーが発生しました （モデル固有の登録）ホストの ゲストシステムの影響を受ける、ホストレベルでコードを実行するために使用できます。
特に、2番目のネストされたレベルのゲスト（別のゲストから起動されたL2）からVMRUN操作を実行すると、nested_svm_vmrunへのXNUMX番目の呼び出しが発生し、svm-> nested.hsave構造が破損します。 。
その結果、L2ゲストレベルで、MSRビットが引き続き使用されている場合でもMSRビットを格納するsvm-> nested.msrpm構造体のメモリを解放してホストのMSRにアクセスできる状況が発生します。環境。。
これは、たとえば、ゲストのメモリをそのユーザースペースプロセスの割り当てられたメモリをダンプすることによって検査できること、またはCPU時間とメモリのリソース制限を簡単に適用できることを意味します。
さらに、KVMは、デバイスエミュレーションに関連するほとんどの作業をユーザースペースコンポーネントにオフロードできます。
この問題は、AMDプロセッサ（kvm-amd.koモジュール）を搭載したシステムで使用されるコードに存在し、Intelプロセッサでは発生しません。
割り込み処理を処理するパフォーマンスに敏感ないくつかのデバイス以外では、仮想ディスク、ネットワーク、またはGPUアクセスを提供するためのすべての複雑な低レベルコードをユーザースペースに展開できます。
問題を説明することに加えて、研究者 彼らはまた、エクスプロイトの実用的なプロトタイプを準備しました これにより、AMD Epyc7351PプロセッサとLinux5.10カーネルを搭載したシステム上のホスト環境でゲスト環境からルートシェルを実行できます。
観察された これは、KVMハイパーバイザーの脆弱性をホストする最初のゲストです それ自体は、QEMUのようなユーザースペースコンポーネントのバグとは関係ありません。 この修正は、XNUMX月末にカーネルで受け入れられました。
最後に あなたがそれについてもっと知りたいのなら メモについては、詳細を確認できます 次のリンクで。