「007」コードはスペクター攻撃を未然に防ぐのに役立つ

ブラックハットはまだ Spectre の脆弱性を大規模に悪用する方法を見つけていませんが、緩和策はすでに登場しています。

チップベンダーやオペレーティング システムのパッチ以外にも、追加の防御策を求める理由は残っています。保護範囲が不完全な状況が依然として存在し、Android スマートフォンの世界では、アップデートが少しずつ提供されるからです。

システム管理者の皆さん、勇気を出して。arXivでは、シンガポールとアメリカの研究者が「007」という名で呼ばれる、コードがSpectreを悪用しようとしているかどうかをチェックする研究を発表しました。また、Virus Bulletinでは、FortinetのAxelle Apvrille氏がAndroidの観点からこのバグを検証しています。

Apvrille氏の研究は、他の研究者から聞いてきたことを裏付けるものです。現時点では、Spectreのエクスプロイトは理論上のものであり、実際に実用化された事例はありません。彼女は、AV-Testのサンプル収集に基づく「Spectreエクスプロイト」に関する記事が相次いだものの、報告されたサンプルはすべて本物のマルウェアではなく、概念実証であったことが判明したと記しています。

彼女はさらにこう付け加えた。「SpectreのPoCとSpectreを悪用するマルウェアの間には大きな違いがあります。PoCを悪意のある実行ファイルに変換するのは、決して簡単なプロセスではありません。」

しかし、だからといってこの種の作業が無意味になるわけではありません。ブラックハットが考案する可能性のある悪質な行為に先手を打つことは良いことです。

検出技術の開発において、アプリール氏が得た2番目の結論もまた朗報だった。スペクターに対する攻撃は比較的簡単に検出できるようだというのだ。

彼女は、「この署名では誤検出がいくつかあると予想していましたが、そうではありませんでした。この不完全な署名は、実際にはかなり優れていることがわかりました」と書いています。

Apvrille が検索したシグネチャ (実際には不可能なほど遅いバイナリ全体の検索手法を使用) は、「ELF x86-64 実行可能ファイル内の Flush+Reload キャッシュ攻撃」を特定することでした。

この手法は速度は遅いものの、AV-Testが収集した概念実証コード内の有効なサンプルをすべて検出しました。スキャンに失敗したサンプルは、いずれにせよ動作しなかったことが判明しました。「それらはすべて破損しており、キャッシュフラッシュ命令が欠落していました。」

Android ユーザーにとってさらに良いニュースがあります。これまでに確認された概念実証サンプルはすべて x86-64 アーキテクチャ用であり、そこから ARMv7 アーキテクチャにコードを簡単に移植することはできません。

ダブルオーセブン

arXivに掲載された論文では、Spectreを攻撃するコードの検出も目指しており、著者らはこれを「Spectre攻撃に対する潜在的な脆弱性に対してコードスニペットをチェックし、修正するためのバイナリ分析フレームワーク」と表現している。

このようなものは既に存在しているが、著者であるシンガポール国立大学の Guanhua Wang、Tulika Mitra、Abhik Roychoudhury、シンガポール工科デザイン大学の Sudipta Chattopadhyay、カーネギーメロン大学の Ivan Gotovchits は、GNU Core Utilities で測定したところ、これらのフレームワークは大きなオーバーヘッドを課すのに対し、007 フレームワークは 2 パーセント未満のオーバーヘッドしか課さないと説明している。

また、彼らは「ポール コッチャー氏が提案した 15 個の Spectre 脆弱コード パターンのうち 14 個を検出したが、これはマイクロソフトが提案した C/C++ コンパイラーの Spectre 緩和策では達成できなかった成果だ」と主張している (コッチャー氏は Spectre の発見者の 1 人で、マイクロソフトの C/C++ コンパイラー修正に対するこの批判を書いた)。

概要では、007チームは、彼らのアプローチには「制御フロー抽出、汚染分析、アドレス分析により、汚染された条件分岐とそれらがメモリアクセスに与える影響を検出する。修正は、すべての条件分岐の後にフェンスを挿入するのではなく、少数のフェンスを選択的に挿入することで実現する」と述べている。

007 で提案された検出アルゴリズムを以下に示します (論文より)。

入力: P: プログラムバイナリ
出力: Φ: Spectreの脆弱性を捕捉する ⟨CB, IM1, IM2⟩ の形式の3つ組のセット
1: Φ ← ∅;
2: TS.policy ← VtoV ▷ 汚染ポリシーを値対値に設定する
3: ステップ ← なし ▷ スペクター検出ステージを初期化
4: instをPの最初の命令とする
5: while inst、ex it do
6: GS ← Interpreter.exe(inst) ▷ GS: グローバル状態
7: TaintEngine.taint(inst, GS) ▷ 汚染を伝播する
8: τ (inst) の場合、▷ oo7 は汚染された命令に対してのみ呼び出されます
9: DS ← oo7.check(inst) ▷ DS: 検出器の状態
10: 終了の場合
11: inst ← P.next() ▷ 次の命令をフェッチ
12: 終了しながら
13: 手順 oo7.check(inst)
14: step ← DS.step() ▷検出段階をチェックする
15: br(inst) の場合 ▷ CB をチェック
16: DS ← DS.setCB(inst) ▷ instがCBをキャプチャする可能性があることを認識する
17: ステップ ← STEP_CB ▷ 検出ステージをCBへ進める
18: TS.policy ← PtoV ▷ ポインタ値汚染を有効にする
19: 終了の場合
20: if (load(inst) ∧ step = STEP_CB) then
21: cb ← DS.CB() ▷ 検出状態からCBを取得する
22: (Dep(cb, inst) ∧ ∆(cb, inst) ≤ SEW) の場合、 ▷ IM1 をチェックする
23: DS ← DS.setIM1(inst) ▷ instがIM1をキャプチャする可能性があることを認識する
24: ステップ ← STEP_IM1 ▷ 検出ステージIM1を進める
25: 終了の場合
26: 終了の場合
27: (mem(inst) ∧ step = STEP_IM1) の場合
28: DS ← DS.setCB(inst) ▷ 検出状態からCBを取得する
29: (Dep(cb, inst) ∧ ∆(cb, inst) ≤ SEW) の場合、 ▷ IM2 をチェックする
30: DS ← DS.setIM2(inst) ▷ instがIM2をキャプチャする可能性があることを認識する
31: Φ ∪ = ⟨DS.CB(), DS.IM1(), DS.IM2()⟩ ▷ スペクターをキャッチ
32: ステップ ← なし ▷ チェッカーをリセット
33: TS.policy ← VtoV ▷ ポインタ値汚染を無効にする
34: 終了の場合
35: 終了の場合
36: if (step = STEP_CB ∧ ∆ (DS.CB(), inst) > SEW) then ▷ SEWの外側
37: ステップ ← なし ▷ 推測ウィンドウを超えた検出をリセット
38: TS.ポリシー ← VtoV
39: 終了の場合
40: if (step = STEP_IM1 ∧ ∆ (DS.CB(), inst) > SEW) then ▷ SEWの外側
41: ステップ ← なし ▷ 推測ウィンドウを超えた検出をリセット
42: TS.ポリシー ← VtoV
43: 終了の場合
44: DSを返す
45: 終了手順

研究者らは、検出コードはシンガポール国立大学のウェブサイトからリクエストに応じて入手可能であると述べている。®