脆弱性
プロセッサに存在するハードウェア脆弱性「Spectre」および「Meltdown」に関する調査が初めて公になってから、4年が経過しました。調査チームはその後、機密情報を漏洩させる可能性のある類似の不具合を複数発見しています。これら脆弱性を使用した攻撃の例も提示されましたが、そのほとんどは実環境で使用される可能性が低いと見られます。この記事では、これらのハードウェアの問題が現在どのような状況にあるのか、これらが企業への攻撃に使用される可能性があるのかを探ります。
Spectreのバリエーション
2018年8月にあった最初の発表では、3つの脆弱性（Spectre v1、Spectre v2, Meltdown）が公開されました。この3つには、複数の共通点があります。
- これら脆弱性の悪用は、（低い権限を使ってではあるが）脆弱なシステム上での悪意あるコードの実行と関わっている。最も危険なオプションは、「感染した」Webサイトにアクセスしたときブラウザーを通じて仕掛けられる攻撃である。
- 実際に悪用するには、数多くの条件が必要である。特に、攻撃対象アプリケーションのコードがデータ漏洩を許す必要があり、また、いわゆる「ガジェット」（ここにアクセスすることで攻撃を可能とする）が必要である。
- データ漏洩そのものは、サイドチャネルを通じて発生する。そのため、データ漏洩の速度は非常に遅い。
- 攻撃がうまくいった場合、不正アクセスの痕跡はまったく残らない。
最後の点こそが、この机上の空論と見える科学的研究に対する特別な関心をあおった要因でした。調査チームはすべての事例において、分岐予測のメカニズムを悪用しています。このメカニズムは20年以上前に提示されたもので、プログラムから実行に関する明確なリクエストを受け取る前に一連の指令を実行することで、パフォーマンスの速度向上を図ります。予測が正しければ、プロセッサのリソースは効率よく消費されます。予測が間違っていれば、演算は単に廃棄されます。
Spectre v1のPoC（概念実証）は、プログラムがアクセスできないはずのデータをプロセッサが読み取れることを示しました。データはキャッシュに保管され、サイドチャネルを通じて取り出し可能です。誤って読み取られてしまったデータはプログラムに転送されないので、このメカニズムは安全だと考えられていましたが、調査チームは間接的にデータを読み取る方法を発見しました。
SpectreとMeltdownに関する研究が発表された後、似たような脆弱性がいくつも発見されました。調査チームは、これらの脆弱性の悪用によって秘密のデータを取り出す新たな手法を探し続けています。Intelは影響を受けるプロセッサを表にまとめていますが、最初に提示された3つの脆弱性に加え、20以上の問題がリストアップされています（英語ページ）。
Spectreに対抗するには
プロセッサの脆弱性を悪用しにくくするための手段は、理論上3つあります。既存プロセッサに対するマイクロコードアップデート、新しいCPUの修正、ソフトウェアアップデートです。本当に問題を軽減するには、多くの場合、ファームウェアのアップデートとソフトウェアのアップデートを組み合わせる必要があります。一部の脆弱性をカバーするマイクロコードアップデートは、2013年の第4世代（Haswell）以降のIntelプロセッサ向けに入手可能となっています。ハードウェアレベルの解決策は、第8世代IntelプロセッサとAMDのZen 2に初めて実装されました。
ソフトウェアレベルの解決策は、一筋縄ではいかない可能性があります。例えば、Spectre v1およびSpectre v2対策としてのLinuxカーネル修正方法については、どんなものがあるのかこちらのページ（英語）で確認できます。特定のシステムの目標や目的に応じ、幅広い手段が議論されました。投機的コード実行を完全に無効にする方法もその一つですが、実行すればCPUのパフォーマンスに深刻な影響が出る可能性があります。
大規模サーバー群のパフォーマンスに頼るビジネスモデルを採用する組織の場合、Spectre対策による最も目立った影響といえば、このようなパフォーマンスの低下でしょう。PhoronixがWebサイトで紹介している比較的最近のベンチマークテストでは、さまざまなサーバーアプリケーションのパフォーマンスを調査していますが、Linux OS 上でSpectre対策を全部有効にした場合、平均して25%のパフォーマンス低下が見られました（英語サイト）。
実際の攻撃と概念実証
攻撃の種類が多いにもかかわらず、Spectreを使ったデータ窃取は理論上の脅威にとどまっています。確かに個別の調査では何らかのコードによるデータ漏洩が実演されていますが、だからといってこのコードを実際のシステムに対して使えるわけではありません。これらのデモまたはPoCには、一般的に以下のような制約があります。
- デモで実演されているのは、ランダムなデータの漏洩である。実用的な価値はなく、攻撃者が以前にアクセスできなかった無作為の情報にすぎないかもしれない。
- 調査に当たっては、例えばシステムへのアクセス回数に制限が設けられていないなど、攻撃に理想的な条件が作り出されている。そうした条件下であれば、データを引き出すのに込み入った方法を取る必要はない。
- デモでは実際にデータ侵害が起きているが、かなり非現実的な条件下で行われている。
（起こりうる結果という観点から）最も目を引くPoCは、NetSpectreです（英語資料）。調査チームは、何とかリモートからの悪用を実演することができました。ただし、NetSpectreには明白な限界があります。データ転送速度と15〜60ビット/時とデータ転送レートが低く、取り出されたデータには大量のジャンクトラフィックが含まれる上に、攻撃を成功させるには攻撃対象サーバー上の脆弱なコードが「正しい場所に」なければなりません。
できるだけ実環境に近い条件での実践的な攻撃は、昨年に2つ提示されました。まず一つは、3月にGoogleが提示した、RAMからデータを取り出すことができるWebページ「https://leaky.page/」（英語）です。9月には、調査時点で最新版でありSpectre対策（Webページをブラウザープロセスごとに分離する）が実装されたGoogle Chromeバージョン92に対するSpook.js攻撃が実演されました。Spook.jsでは、実際にデータ窃取が可能でした。調査チームは、SNSのログイン情報、パスワードマネージャーのデータ、プライベートクラウドにアップロードされた画像にアクセスできています。しかし、いずれの場合も、データを盗むには「感染した」ページが同じドメイン内にある必要がありました。例えば、Tumblrのパスワードを盗むためには、Tumblrの別のページに悪意あるJavasSriptをアップロードしておかなければなりません。
どれほど危険な脅威なのか
Spook.jsは、Google Chromeに対するソフトウェアパッチで中和されました。したがって現時点では、今すぐ現実的な条件下でSpectre系の脆弱性が悪用される恐れはありません。既知の攻撃はいずれも極めて複雑で、攻撃者側には非常に高いスキルが求められます。
現実味のあるPoCはほとんどパッチが公開されており、パッチがない場合でも、悪用するには多数の条件を満たす必要があります。現実に起きたとされる「Spectreの悪用」に関するニュースの確証が得られたことはありませんが（英語）、それでもセキュリティ各社は万一に備えて既知の攻撃を検知するツールを追加しました。そのため、自社の保護には既存のマルウェア検知メカニズムが有用である可能性は高いと考えられます。
しかし、Spectreを完全に無視するべきではなく、継続的な調査が重要です。わずかながらでも、痕跡を残さずにデータを漏洩可能とするマルウェアをインストールしなくても成立する攻撃という「最悪のシナリオ」が発見される可能性はあります。
盗みだすデータが労力に見合った価値を持っているなら、ハードウェアの脆弱性を使用した標的型攻撃も、理論上は可能です。このようなリスクに対して保護を講じるには、可能性のある攻撃媒介を特定する、OS開発者の推奨事項に従うかパフォーマンスの深刻な低下と引き換えにしてでも保護手段を実装する、といった本格的な投資が必要です。しかし、大企業も含めほとんどの企業にとって、ソフトウェア開発元、OS開発元、プロセッサ製造業者、そしてセキュリティソリューションに頼ることで十分な対策が見込めます。
ヒント