仮想化
フランスのクラウド事業者はDebianに修正パッチをバックポートし、ダウンタイムが発生する可能性があったにもかかわらず、顧客の同意を求めませんでした
フランスのクラウド事業者OVHは、Linuxカーネルベースの仮想マシン(KVM)に存在する重大なゲスト・ホスト間エスケープ脆弱性「Januscape」の修正パッチを迅速に展開するにあたり、オーストラリア・シドニーのデータセンターをクラッシュテストの実験台として使用したことを明らかにしました。
Januscape(別名CVE-2026-53359)は、ゲストVMへのroot権限を持つ攻撃者がホスト上でrootとしてコードを実行したり、そのマシンをクラッシュさせたり、他のすべてのゲストVMを乗っ取ったりすることを可能にする脆弱性です。
ゲスト・ホスト間エスケープが広範囲に悪用される事態は悪夢のシナリオです。多くの大手クラウドはKVMを使ってサーバーを仮想マシンに分割し、そのゲストを顧客に貸し出しているためです。攻撃者が1つのテナントのVMにアクセスし、それを足がかりに他のゲストやホスト全体をクラッシュさせる可能性があるという事態は、顧客のワークロードを完全に隔離された環境で実行するというクラウド事業者の約束を根底から揺るがす、恐るべき事態と言えます。
そのため、この脆弱性の修正は最優先事項とされました。
月曜日、フランスのクラウド事業者OVHのCISOであるJulien Levrard氏は、約1万台規模のホスト(約100万台の仮想マシンを稼働)に対する緊急パッチ適用作業をどのように進めたかを公表しました。この長文の投稿は、クラウド事業者が重大なセキュリティインシデントにどう対処するかを、異例なほど詳細かつ率直に語ったものです。
この脆弱性を緩和する方法の一つは、各ホストのLinux KVM上に2行の設定ファイルを作成し、ネスト型仮想化を無効化することでした。しかしOVHには、テナントがネスト型仮想化を必要としているかどうかを把握する手段がなく、また同社自身もVMを別の物理ホストへ移動させる際にこの機能に依存しているため、この選択肢は採用できませんでした。
ライブパッチの適用も、不安定化を招く恐れがあることから受け入れがたい選択肢でした。パッチ適用済みホストへのライブマイグレーションという方法もありましたが、これはプロセスが遅く、テナントVM全体をJanuscapeフリーの環境へ移行するのに数か月かかる可能性があるとの判断から、OVHはこの案を却下しました。
そこで同社は、本番環境で使用しているDebianディストリビューションにJanuscapeの修正をバックポートしたうえで、全ホストを再起動するという方針を決定しました。顧客には事前に通知するものの、選択の余地は与えないというものです。これは、単一ホストに依存している顧客には一定のダウンタイムが発生することを意味しましたが、OVHの経営委員会は次の3つの理由からこの方針を承認しました。
-
攻撃が発生する前にパッチを適用する必要があったこと
-
個別対応にすると、OVHクラウド全体が脆弱な状態にさらされる期間が長引いてしまうこと
-
できるだけ多くの顧客を守り、少数への影響は許容するという方針
また、OVHはパッチ適用計画について沈黙を貫くことも決めました。
「緩和策の実行中、インフラがまだパッチ未適用の状態にあるうちに詳細を発表すれば、顧客のリスクを大幅に高め、一部の顧客が公開されているエクスプロイトを『試してみる』ことにつながりかねませんでした」とLevrard氏は記しています。
危険を冒したダウンアンダー(南半球)での挑戦
パッチ適用の手腕を試すため、OVHはまずシドニーリージョンで修正を行うことを決めました。シドニーは同社のリージョンの中でも比較的小規模で、オーストラリア東海岸がフランスより8時間進んでいることから、欧州のチームが自国の業務時間内に作業を行えるうえ、シドニー現地では比較的閑散とした時間帯に実施できるという利点がありました。同社はこうして、まずオーストラリアで経験を積んでから、より広範囲への展開を計画しました。
OVHの計画では、再起動を波状に実施することとし、高密度リージョンで同時に15台、その他のリージョンで5台のホストが障害を起こした場合には「停止しきい値」を発動して作業を止めることになっていました。
しかし、この「波」は単にラック順に進めるだけの単純なものではありませんでした。
「このような作業において顧客にとっての主なリスクは、再起動そのものではなく、同一プロジェクトの複数インスタンスが同時に中断されることです。アプリケーションの耐障害性は、プロバイダー側の障害に対応できるように設計されている必要があります」と、このプロジェクトに関するOVHのブログは説明しています。「可用性を高めるために複数のホストにワークロードを分散させている顧客が、すべてのインスタンスを同時に失うようなことがあってはなりません。顧客のデプロイ設定で定義されているアンチアフィニティルールを単に遵守するだけにとどまらない対応を取ることにしました」
「そのため、複数のホストにインスタンスが分散している各顧客プロジェクトについて、当社のオーケストレーターがコロケーショングラフを算出します。同一プロジェクトのインスタンスを稼働している2台のホストが、同じ時間枠内で同時に再起動されることは一切ありません。互いに排他的な波が定義され、同一のアンチアフィニティクラス内で次のホストを起動する前に、前のホストが復旧している必要があります」
パッチ適用作業では、いくつかのトラブルにも見舞われました。ハイパーバイザー再起動後に一部のVMが再起動しない事態が発生し、強制シャットダウン中にデータ破損が発生したケースもありました。OpenStack APIが不調をきたし、数時間にわたってHTTP 503エラーが発生したため、あるパッチ適用の波を延期せざるを得ませんでした。カナダのある拠点では「APIトラフィックが通常のピーク時の10倍に達し、管理システムとサポートチームが対応しきれない事態」に陥りました。
ハードウェアの不具合
作業の過程で、一部のハードウェアが完全に故障するケースもありました。
「初日の夜には、6,000台のホストのうち約20~30台が自力で復旧しませんでした」とLevrard氏は明かし、原因として「メモリモジュールの不良、BIOS設定の問題、無効化されたネットワークインターフェース」を挙げています。中にはCMOSバッテリーの交換が必要な機体もありました。
このCISOは、OVHの取り組みについて、プロジェクトの規模を踏まえれば「発生した障害件数や顧客への影響は非常に妥当な水準に抑えられた」ことから「注目に値する成果」だったとの見方を示しています。
ただし同氏は、今後改善すべき点もあると考えています。
「今後数か月の間にも、さらなるカーネル脆弱性の公表が予想される以上、この緊急対応手順を再び実施する必要が出てくるのは明らかです」と同氏は記しています。「次回に向けては、再起動そのものの影響を管理する面でも、顧客への事前通知や作業中のサポート提供の面でも、改善を図る必要があります」
同社は現在、事後分析を実施しており、これによってプロセスの改善につなげたい考えです。®
