Google Cloud の KVM セキュリティを強化する 7 つの方法

Google Cloud では、多くの研究者に検証されたオープンソースの KVM（Kernel-based Virtual Machine）ハイパーバイザを Google Compute Engine と Google Container Engine の基盤として使い、研究とテストを基にさらなる KVM のセキュリティ強化、保護に投資しています。その成果は KVM プロジェクトに還元し、オープンソース コミュニティ全体の利益となるように取り組んでいます。

次のリストは、皆さんのアプリケーションの安全とセキュリティを向上させられるように、私たちが KVM のセキュリティを強化するために実施している主な方法をまとめたものです。

1. 脆弱性の発見を率先 : Google の KVM には、セキュリティと分離のために複数のレイヤが組み込まれ、私たちは常にその強化に取り組んでいます。Google のクラウド セキュリティを担当するスタッフには、KVM セキュリティの分野で世界最高峰のエキスパートも在籍し、KVM や Xen、VMware ハイパーバイザの多様な脆弱性を明らかにしてきました。これまでに発見し、修正した KVM の脆弱性は 9 件。同じ期間に、オープンソース コミュニティが発見した、Google Cloud Platform（GCP）に影響のある KVM の脆弱性はありません。
2. 攻撃可能範囲を縮小 : Google は、未使用のコンポーネント（たとえば古いマウス ドライバや割り込みコントローラ）を取り除き、エミュレートされている命令セットを制限することで、KVM のセキュリティ向上に貢献しています。これにより、攻撃者が攻撃やパッチに利用できる範囲を狭めさせることになります。また、その他のコンポーネントについても、セキュリティを高めるために変更を加えています。
3. QEMU の不使用 : Google では、QEMU（ユーザー スペースの仮想マシン モニタ、ハードウェア エミュレータ） を使用しません。代わりに、以下の点で QEMU よりもセキュリティに優れる独自のユーザー スペース仮想マシン モニタを作成し、使用しています。
   QEMU は、多数のホストとゲスト アーキテクチャの組み合わせに加えて、異なるモードやデバイスをサポートしているために複雑さが増大しています。Google のエミュレータは 1 つのアーキテクチャと少数のデバイスしかサポートせず、とてもシンプルです。現在はホスト / ゲストの組み合わせによるクロス アーキテクチャをサポートしないことで、余計に複雑になることはなく、攻撃の可能性も減らしています。
   Google の仮想マシン モニタは、シンプルさとテストのしやすさを重視したコンポーネントから構成されています。ユニット テストは複雑なシステムのバグを減らすうえで効果的ですが、QEMUのコードにはユニット テストが含まれず、ユニット テストを非常に困難にする多数の相互依存が含まれています。
   QEMU は VENOM に代表されるセキュリティ関連のバグが、これまでに何度も見つかりました。今もコード内に何らかの脆弱性が残されているのか、明らかではありません。
   Google の仮想マシン モニタには、これまでセキュリティ上の問題はありません。
4. ブートとジョブ間の通信 :私たちが実装したコード プロビナンスのプロセスは、マシンが正常にブートすることを確認できるようにしてくれます。各 KVM ホストは、ピア ツー ピアの暗号化キー共有システムを作り出し、そのホストで実行しているジョブと共有して、ジョブ間の全ての通信が明示的に認証され、認可されたものであるようにしています。
5. コード プロビナンス : KVM でどのようなソース コードが実行されているのか、どのようにビルドされたのか、どのような設定が行われているのか、どのようにデプロイされたのかを追跡できるように、カスタム バイナリと設定を検証するシステムを開発して、開発プロセスにも統合し、利用しています。
   私たちは、ブート ローダーから KVM、お客様のゲスト VM までの各レベルでコードの整合性を検証しています。
6. スピーディで適切な脆弱性対応 :重大なセキュリティ脆弱性に備えて、KVM にパッチを適用する上での厳格な社内 SLA とプロセスを定義しています。Compute Engine のベータ リリース後の 3 年間で、Google の KVM 実装が重大なセキュリティ パッチを必要としたことは一度もありませんが。
   KVM 以外の脆弱性については、最大限のセキュリティを確保し、該当するすべてのコンプライアンス要件を満たしたうえで、 Google の社内インフラストラクチャからスピーディにパッチを適用しています。ほとんどの脆弱性は、お客様に影響を与えることなく解決されています。アップデートについては、契約および法的な義務によって必要とされる情報をお客様にお知らせしています。
7. リリースの綿密な制御 : KVM のアップデートには、コンプライアンス要件と Google Cloud のセキュリティ管理に基づき、厳格なロールアウト ポリシーとプロセスを定義しています。KVM のビルド システムとリリース管理操作にアクセスできるのは、Google 社員の中でも小さなチームだけに制限されています。

• KVM のセキュリティ
• KVM のセキュリティ改善に関する Andrew Honig のプレゼンテーション
• 効率の良い KVM のセキュリティ強化に関する Steve Rutherford のプレゼンテーション

FAQ

この攻撃を作動させるには、ターゲット VM と攻撃者の VM が同じ物理ホストに配置されなければなりません。また攻撃らしい攻撃を行うには、意図的にターゲットとなる暗号システムを動作させる技量を攻撃者が有している必要もあります。

サイド チャネル攻撃は、一般的に暗号化キーに対して行われます。情報をリークするようなサイド チャネル攻撃があれば、通常暗号化ライブラリの開発者によって直ぐに対処されることから、Google Cloud のお客様には、暗号化ライブラリがサポートされていて、常に最新の状態であることを確認するように勧めています。

VENOM についてはどうですか？
VENOM が影響を及ぼすのは QEMU です。Compute Engine と Container Engine はいずれも QEMU を使用していないので影響を受けません。

Rowhammer についてはどのように対策していますか？
Google Project Zero チームは、クライアント プラットフォームに対する現実的な Rowhammer 攻撃が起こりうることを示しました。

Google のプロダクション マシンは、エラーを削減するためにリフレッシュ レートを倍速にし、Rowhammer に誘発されたエラーを検出し訂正する ECC RAM を使用しています。1 ビットのエラーは自動的に訂正し、2 ビットのエラーが検出されると問題を起こす可能性があるゲスト VM を強制終了させます。異常な数の Rowhammer エラーを引き起こしたプロジェクトに対してはアラートを生成します。検出不能な 3 ビット エラーは理論的には可能ですが、起きることはまず考えられません。Rowhammer 攻撃は、2 ビットや 3 ビットのエラーに対する大量のアラートを引き起こし、検出されます。

最近の論文に、KSM の KVM モジュールを使って Rowhammer 攻撃を作動させる方法が掲載されています。KSM は Linux のメモリ重複排除機能であり、カーネル スレッドとして動作してメモリを定期的にスキャンし、複数の VM がマッピングしている同じ内容のメモリ ページを見つけると 1 つにマージします。KSM によるメモリの重複排除は、データを保持する物理トランジスタのどこを「叩く」べきかを探しやすくするため、これを悪用すれば、同じ物理ホストで実行されている他の VM の同じビットを攻撃目標にすることが可能になります。

Compute Engine と Container Engine は KSM を使っていないため、この種の攻撃の影響を受けません。ただし、別のメカニズムによる同様の攻撃が生じた場合に備えて、Google はそれを検出して問題の影響を最小限にする準備を整えています。

KVM の脆弱性の影響を減らすために Google はどのようなことをしていますか？
これまで KVM で発見された脆弱性の原因を評価してきました。ほとんどの脆弱性は、歴史的な理由でカーネルにあるコード領域で見つかっていますが、最新のハードウェアで最新のオペレーティング システムを動かせば、パフォーマンスに大きな影響を与えずに取り除くことができます。私たちは現在、パフォーマンスに大きな影響を与えることなく、カーネル内のエミュレーション機能をカーネル外に移す作業を進めています。

Google のセキュリティ チームは、どのように早い段階で KVM の脆弱性を見つけているのですか？
KVM 用のプロプライエタリなファジング ツールを作り、利用しています。また KVM の新しい機能や新バージョンを導入するたびに、セキュリティ問題の発見だけを目的とした徹底的なコード レビューを行っています。その結果、この 3 年間で KVM のセキュリティ脆弱性を多数発見しました。そのうちの約半分がコード レビュー、残り半分がファジング ツールで見つかったものです。

* この投稿は米国時間 1 月 25 日、Technical Lead Manager である Andy Honig と、Senior Product Manager である Nelly Porter によって投稿されたもの（投稿はこちら）の抄訳です。

- By Andy Honig, Technical Lead Manager and Nelly Porter, Senior Product Manager