GhostRace（ゴーストレース）という脆弱性……再び顕れたCPUの投機的実行へのサイドチャンネル攻撃手法。

tomshardware.comの記事である。


これは、VUSec と IBMが公表した攻撃手法のようだ。今や当たり前となっているCPUの投機的実行機能で必ず生じるリソース競合と共有という部分を使ってデータの一部を読み取るというものだ。いわゆるMeltdownとSpectreの延長線上にある攻撃手法である。お隣のレジスター（L0キャッシュ）にあるデータを取り出してと指示すればもしかするとデータがあるかもしれない。そういう手法を使って抜き出すというものだ。投機的実行では、次々来るデータをどんどんデコードし演算器に流し込むスタイルである。もちろん分岐予測を掛けるので、そこで順番待ちが掛かるものもあるが、基本的には大きく外れると分かっているもので無ければ、実行に回される。もし、実行で失敗すれば送られた演算ポート番号の情報や理由を付けてリタイアさせて、もう一度処理させれば良い。

これが投機的実行だ。即ち結果を待たずにどんどん演算器に流し込むのだ。失敗したら差し戻してもう一度違う回路や手順で処理させる。これが、脆弱性になるわけだ。何故なら、回路の掃除を一回毎にいちいちしないからだ。そんな時間もないから、やらないのだ。そうすると残滓が残るし、お隣のレジスタで別のデータが待機していることもある。だから、お隣の部屋にこんこんノックして、「あなたはだあれ？」と質問するコードを実行させると、結果が帰ってくるかもしれない。

これが、サイドチャンネル攻撃の基本である。この攻撃をするには、レジスタや演算器同士がどのように周囲との協調処理をしているかを知る必要があり、それをどうやってデータの抽出に使うかというアイデアの問題である。

一方でハードを作っている側からすればこの攻撃に対する対策は、その都度処理に割り込んで、キャッシュクリアを掛けるか、厳格な越境ポート処理に対する規制を掛けるかのどちらかしかない。だから、もし対策を取るとなると性能が大幅に下がる。命令セットなどの仕組みによっては、キャッシュ構造を再帰的に使うことで高速な処理を達成しているものもあるので、完全な厳格処理を与えると性能が1/1000以下に落ちる可能性もあるとされる。そういう理由で消えた命令セットとしてはIntel SGXがあるが、あれは元々セキュリティの効率命令と不可視領域だっただけに、意味を失ったわけだ。

これは、半導体開発をする企業に取ってはまさしく信頼性を揺るがす脅威であるわけだ。
まあ、家庭などで使うクライアント環境ではそれほど影響はないけどね。少なくとも、今のWindowsなんかはかなりリスクは低い。OSの再起動が求められるアップデートが毎月あるし……。

これは、例えインターネットに繋がっていたとしても、個別ローカルクライアント環境で影響を受ける事は殆ど無い。サイドチャンネル攻撃の大半はミッションクリティカル環境のデーターセンターやハイパフォーマンスコンピュータ、セキュリティサーバーである。

何故なら、コンピュータの再起動頻度が高いこと、重要なデータを持っていても、利用する機会が限られているからである。サイドチャンネル攻撃でのデータ取り出しは、前後左右に攻撃者が求めるデータの残滓が含まれている必要があり、それを取り出すのが攻撃の主体である。即ち攻撃者が特定のデータを取り出すわけではなく、無作為に抽出したデータからパスワードやユーザー情報などがヒットすれば、そこを皮切りに重要な鍵を取り出せる可能性があるというものに過ぎない。

それも、今のワンタイムパスなどが使われるようになった時代では、クライアントだけでは完結しないので、個人を狙ってもあまり意味が無いわけだ。もちろん、セキュリティソフトの導入などが不十分で常時ネット接続した環境で、何年もPCを再起動していないなら、攻撃を受けている可能性はゼロでは無い。その場合でもリソースを一定程度常に消費しているはずなので、LinuxならTop監視を、Windowsならタスクマネージャーなどで時々リソースを見ていれば分かるだろう。


サーバーでは用途によって常時2割～7割ほどのリソースを消費しているため、そのうちの3～7%程度（平均5%）をサイドチャンネル攻撃に振られていても分からないと言うわけだ。これが、サイドチャンネル攻撃の怖いところなのだ。大規模なサーバーやワークステーションだとこれが脅威になるわけだ。

今回のGhostRaceは、殆ど全ての投機的実行が出来るCPUで見られる脆弱性であるとされる。
だから、Armもx86も投機的実行が出来るなら対象になる。サーバーにとっては新たな脅威がやってきたという訳だ。まあ、Meltdownなどの登場からもう何年も経つが、この手の脆弱性、毎年1つ以上新しいものが生まれているので、今更ってところである。どちらかというとサーバー側にとって困るのはもしパッチが出たとしてそれが、どれほど性能を落とすのかと、それを導入しないことで攻撃を受けて漏れる危険性と、パッチによる性能の低下で生じるリソース低下の影響のどちらが差し迫った脅威なのかの判断が難しいことだろう。

クライアント環境ならあくまで、そのクライアントを使う個人が納得または我慢出来ればそれで終わりだが、サーバーはそうもいかない。下手すれば、顧客からの苦情やサービス品質の低下という形で帰ってくるからだ。