防いだはずのSpectre再燃、割り込み注入が暴く安全神話の嘘

深夜の障害対応で、バグを修正したはずのコードが、全く予期しないタイミングの競合（レースコンディション）によって再び牙をむく――。我々エンジニアにとって、これほど胃が痛くなる瞬間はない。2018年に世界中を震撼させたCPUの投機的実行脆弱性「Spectre」と「Meltdown」。あれから数年が経ち、OSカーネルやハイパーバイザへのパッチ適用、コンパイルオプションの調整といった「総力戦」を経て、この問題は過去の遺物になったと誰もが信じたかった。しかし、マサチューセッツ工科大学（MIT）のCSAILが発表した「TONTOU（Time-of-Neutralization to Time-of-Use）」は、我々が築き上げた防御壁が砂上の楼閣に過ぎなかったことを冷酷に突きつけている。

今回の攻撃が狙うのは、Spectre v2の緩和策として導入された「状態の無効化（Neutralization）」の直後に生じる、極小の「隙」である。CPUがコンテキストスイッチ時などに分岐履歴バッファ（BHB）や戻りアドレススタック（RSB）をクリアした直後、実際にそのバッファが使用されるまでのわずかな時間に、タイマー割り込みを極めて精密なタイミングで注入する。これにより、クリアされたはずのバッファを攻撃者が意図した状態に「再汚染」することに成功したのだ。これは、マルチスレッドプログラミングにおける「TOCTOU（Time-of-Check to Time-of-Use）」バグを、ハードウェアの投機実行制御のレイヤーで再現されたようなものである。一度は防いだはずの脆弱性が、割り込み処理というOSの根幹機能を利用してすり抜けていく様は、まさに「無限ループ」に陥ったデバッグ作業のように、我々を絶望的な徒労感へと誘う。

「理論上は可能だが、実用的な攻撃は困難である」――。セキュリティベンダーやチップメーカーが好んで使うこの常套句は、今回の検証データの前では完全に無力化される。MITの研究チームがAMDのZen 2環境で行ったデモの数値は、あまりにも生々しく、そして破壊的だ。

最新の緩和策をすべて有効にした状態であるにもかかわらず、攻撃者は91.97%という極めて高い精度、そして毎秒5.47バイトという実用的な速度で、カーネルメモリから任意のデータを吸い出すことに成功した。さらに恐ろしいのは、わずか10回の試行のうち5回、時間にしてわずか18分で、システムの最高権限を掌握するためのルートパスワードハッシュが格納された「/etc/shadow」ファイルを特定したという事実である。

これは、クラウド環境におけるマルチテナントの境界線が、ハードウェアレベルで容易に突破され得ることを意味している。我々が日々デプロイしているコンテナや仮想マシンは、ハイパーバイザによって厳密に隔離されていると信じられているが、物理CPUの投機実行ユニットという「物理的な共有資源」を介して、隣のテナントの秘密鍵やパスワードが漏洩しているのだ。この現実を前にして、なお「パッチを当てているから安全だ」と言い切れるインフラエンジニアがどれだけいるだろうか。セキュリティ対策を「チェックリストの消化」と捉えるコンプライアンス的思考が、いかに現場の安全を脅かすかを、この91.97%という数字は雄べきに物語っている。

この深刻な脆弱性に対する半導体ジャイアントたちの対応の温度差は、我々開発者に「誰を、どの程度信頼すべきか」という重い問いを突きつけている。各社の対応姿勢を比較すると、その温度差は一目瞭然だ。

AMDは、この問題を真摯に受け止め、「AMD-SB-7061」として脆弱性を公開し、Linuxカーネルパッチを通じた緩和策の提供を迅速に表明した。自社のアーキテクチャが抱えるリスクを認め、コミュニティと共に修正へ動く姿勢は評価に値する。しかし、一方でIntelとArmの対応は、我々エンジニアの感覚からすれば、強い違和感を覚えざるを得ない。

Intelはバグ報奨金を支払いながらも、「実際の悪用には多くの要因に依存するため、ただちに緩和策を講じる必要はない」と静観を決め込み、Armにいたっては「受動的な漏洩に該当するため、積極的に保護を行う対象ではない」と切り捨てた。この態度は、ビジネス上の影響やパフォーマンス低下（ペナルティ）を嫌った、極めて政治的な判断に見える。Spectreの緩和策は、往々にしてCPUの処理能力を数％から数十％低下させる。彼らにとって、ベンチマークスコアの低下は死活問題であり、実害が広く報告されるまでは「静観」するのが最も経済合理性に適っているのだろう。しかし、その「信頼のコスト」を支払わされるのは、常に現場のシステムを運用する我々エンジニアであり、エンドユーザーである。

ハードウェアが牙をむく時代において、我々ソフトウェアエンジニアが取るべきアプローチは、もはや「ハードウェアを信用しない」というゼロトラストの思想を、物理レイヤーにまで拡張することである。CPUメーカーが提供するパッチを待つだけの受動的な姿勢では、次の「TONTOU」のような未知のサイドチャネル攻撃を防ぐことはできない。では、我々は明日から実務でどう動くべきか。具体的な処方箋として、以下の3つのアプローチを提案したい。

• カーネル空間とユーザー空間の物理的な分離の徹底: アドレス空間配置のランダム化（KASLR）だけに頼るのではなく、機密性の高い処理を行うプロセスを、物理的に異なるコア（コア隔離）や、投機実行の影響を受けにくい専用のセキュアエンクレーブ（Intel SGXやAWS Nitro Enclavesなど）へ明示的に割り振るアーキテクチャ設計を導入すること。
• 機密データのメモリ滞留時間の極小化: 暗号化キーやパスワードハッシュなどの機密データは、使用後直ちにメモリ上からゼロクリア（ゼロフィル）し、投機実行によって読み取られる窓口を物理的に狭めるコードを徹底すること。
• 異常なコンテキストスイッチや割り込み頻度の監視: TONTOU攻撃は、極めて精密なタイマー割り込みの注入を必要とするため、システム全体の割り込み発生頻度や、不自然なキャッシュミス率の急増を検知するアノマリ検知を監視ダッシュボードに組み込むこと。

最後に、我々コミュニティに問いかけたい。我々はいつまで、物理的な設計ミスをソフトウェアのパフォーマンスを犠牲にすることで隠蔽し続ける「泥縄式のパッチ当て」を許容し続けるのだろうか。真に安全なプロセッサアーキテクチャへの移行を、我々買い手の側から強く要求していく時期に来ているのではないだろうか。