source code: https://github.com/icchy/tscjammer

1. VMMを用いたタイミング
ベースサイドチャネル攻撃に
対する緩和策
東京農工大学
市川遼

2. 背景
● 脆弱性を悪用した攻撃は増加の一途にある
○ 基本的にはパッチを当てれば修正可能
● 多くはパッチによって解決されるが、根本的な修正が難しいものもある
○ 仕様レベルの機構を利用しているもの
○ 利便性にために存在するもの
○ サイドチャネル攻撃は極めて防ぎにくい攻撃の一つである
● こうした攻撃を汎用的に防ぎたい

3. サイドチャネル攻撃
● 間接的に秘密データを読み出す攻撃
○ 直接的にデータをリークしないため検出・防御が困難
○ その多くは正常な仕様を悪用したもの
● 攻撃例
○ Spectre, Meltdown
■ CPUの投機的実行や分岐予測などを利用した攻撃
■ 本発表ではこの攻撃へ対する緩和策を提案
○ RSA fault attack
■ RSA-CRTに対する攻撃
○ XS-Search
■ ブラウザのクロスドメインで保護されない要素を用いた攻撃
● 暗黙の内に利用されているものがターゲットになりうる

4. サイドチャネル攻撃に使われる要素
● 差異を観測することのできる要素
○ タイミング
■ プログラムの実行にどれだけ時間を要したか
○ キャッシュ
■ 最近どのようなデータが使われたか
○ レスポンス
■ プログラムが正常に終了したか
■ プログラムそのものの出力結果
● これらは全て正常な動作範囲内で観測できる

5. Spectre, Meltdown
● 細かい違いはあるが本質的には同じ
○ 高速化のために暗黙的に行われる動作の副作用をキャッシュから読み取る
● Meltdownの例
○ CPUには高速化のために先読みしてコードを実行する機能がある
○ 投機的実行がされる時はメモリのアクセスに対する保護が働かない
○ 先読みした結果が頻繁に当たるとキャッシュされる
○ 意図的にキャッシュを学習させて、ヒットしたか否かで別の範囲にある値をリーク
■ キャッシュヒットの発生は時間を計測することで検知可能

6. 対策
● ユーザーランドでの根本的な対策は無い
○ CPUに起因する脆弱性であるため
● 汎用的な緩和策
○ 読み出すアドレスをわからなくする (ASLR)
○ 同じページテーブル上に重要な情報を含んだメモリが乗らないようにする (KPTI)
→ 古いCPUでは性能低下を引き起こす
● ソフトウェアでのAd-hocな対策例
○ Chrome: サイト毎にプロセスを生成して Cross-Siteのデータを読めなくする

7. 提案手法
● サイドチャネル攻撃に必要な情報を欠落させる
○ タイミングベースのサイドチャネル攻撃には高精度な時間計測が必要
○ タイマーの精度が十分に低い場合、攻撃は失敗する
● タイムスタンプカウンタとして使われる命令にノイズを載せる
○ RDTSC
○ RDTSCP
○ cf. BitVisor Summit 7 筑波大学 大山恵弘 "BitVisorによるOSの見かけ上10倍速実行"
■ https://www.bitvisor.org/summit7/slides/bitvisor-summit-7-4-oyama.pdf
● 適当な乱数を発生させ、戻り値に加算
● BitVisorで実装
○ OSに手を加えること無くベアメタル環境で適用可能

8. 補足
● LinuxはRDTSCが信用できるかを監視する
● 不安定になるとHPETに切り替える
○ tsc=reliable をカーネルパラメータに追加すると常に RDTSCを使う
[ 80.981566] clocksource: timekeeping watchdog on CPU4: Marking
clocksource 'tsc' as unstable because the skew is too large:
[ 80.981569] clocksource: 'hpet' wd_now: 711dec8a
wd_last: 6b7744b2 mask: ffffffff
[ 80.981570] clocksource: 'tsc' cs_now:
37fffa04eb cs_last: 34f815eaa0 mask: ffffffffffffffff
[ 80.981573] tsc: Marking TSC unstable due to clocksource watchdog
[ 80.981625] TSC found unstable after boot, most likely due to broken
BIOS. Use 'tsc=unstable'.
[ 80.981626] sched_clock: Marking unstable (80611443013,
376117789)<-(81685895057, -704289633)
[ 80.987560] clocksource: Switched to clocksource hpet

9. 評価
● MeltdownのPoCが失敗するかどうかを確かめる
○ github.com/paboldin/meltdown-exploit
○ rdtscが十分不安定なら失敗するはず
● BitVisorを用いて実装
○ noise用のグローバル変数を用意
○ vmmcallで変更
○ LCGで乱数生成しながら、 ±(noise_max/2) をrdtscの戻り値に加算
○ ノイズの幅を0から1000000に設定して成功率を計測
● 環境
○ Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz (6 core)
○ Pop! OS 18.04 (Ubuntu18.04)

10. 結果
● 成功率が安定しないがおおよそ単調減少
● noise: 4000~5000くらいでほぼ0%
○ 3500付近で急激に成功率が落ちる

11. 考察
● そもそも攻撃自体が安定しない
○ 通常状態では80~90%程度
○ 少ないノイズだとむしろ成功率が上がっている？
○ PCの状態 (画面OFFなど) の影響も考慮する必要がある
● 5000 (±2500) でほぼ失敗する
○ 体感では動作そのものに影響は生じていない
○ LinuxのTSC検知機能にも引っかからない
○ 汎用的なmitigationとしては成功している

12. 今後の展望
● 現状では全てのプロセスのTSCの精度が低下
○ BitVisor内のグローバル変数に格納するため
● 特定のプロセスを検知
○ LibVMIなどを用いてプロセスレベルの情報を取得
○ サイドチャネル攻撃を検知してトリガーにする
● 安定性の高い結果を得る方法を模索する