仮想化
フランスのクラウド事業者は、ダウンタイム発生のリスクがあったにもかかわらず顧客の同意を得ないままDebianにパッチをバックポートしていました
フランスのクラウド事業者OVHは、Linuxカーネルベースの仮想マシン(KVM)に存在する重大なゲスト・ホスト間エスケープの脆弱性「Januscape」の修正を迅速に展開するにあたり、オーストラリア・シドニーのデータセンターを実験台として使用していたことを明らかにしました。
Januscape、別名CVE-2026-53359は、ゲストVMへのroot権限を持つ攻撃者がホスト上でrootとしてコードを実行したり、そのマシンをクラッシュさせたり、他のすべてのゲストVMを乗っ取ったりすることを可能にする脆弱性です。
ゲスト・ホスト間エスケープが広範囲に悪用される事態は悪夢のシナリオです。というのも、多くの大手クラウド事業者がKVMを使ってサーバーを仮想マシンに分割し、それらのゲストを顧客にレンタルしているためです。あるテナントのVMに侵入した攻撃者が、それを足がかりに他のゲストやホスト全体をクラッシュさせる可能性があるという事態は、顧客のワークロードを完全に隔離して実行するというクラウド事業者の約束を根底から揺るがす恐ろしい事態と言えます。
そのため、この脆弱性の修正は最優先事項でした。
月曜日、フランスのクラウド事業者OVHのCISOであるJulien Levrard氏は、約1万台規模のホスト(約100万台の仮想マシンを稼働)に対する緊急パッチ適用作業をどのように行ったかを公表しました。これは、クラウド事業者が重大なセキュリティインシデントにどう対処しているかを異例なほど詳細かつ率直に語った投稿となっています。
この脆弱性を緩和する方法の一つは、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の取り組みは「注目に値する成果」だったと考えています。
ただし、同氏は今後さらに改善が必要だとも見ています。
「今後数か月のうちにさらなるカーネル脆弱性の開示が続く可能性を考えると、この緊急対応手順を再び実施しなければならなくなることは明らかです」と同氏は記しています。「次回はさらに改善する必要があります。再起動そのものの影響を管理する面でも、作業中に顧客への事前通知やサポートを提供する面でも、です」。
同社は現在、今後のプロセス改善につなげるべく事後分析を実施しています。®
