Transcript 09 - qwik.jp

Program Surfing I
プログラム解析いろいろ
• Inference of Field Initialization
未初期化オブジェクトの使用を推論
• Taming Reflection
リフレクションを通常のコードに変換する動的解析
• Patching Vulnerabilities with Sanitization Synthesis
XSSなどを引き起こす入力文字列の自動特定
石尾 隆
[email protected]
2011/06/29
1
Inference of Field Initialization
❖著者：Fausto Spoto and Michael D. Ernst
❖提案手法： プログラムの各時点で，オブジェク
トのフィールドが初期化されているか推論
 静的解析
 Java バイトコードを解析
 オブジェクト型の変数について以下の情報を出力
 null でないことが保障されるか否か（@NonNull）
 フィールドに未初期化のものがあるか（@Raw）
2
2011/06/29
研究の背景
❖未初期化のフィールドを知らずに使ってしまう
と，間違いのもとになる
class X {
public X() {
this.field = 0; // フィールド初期化
init(); // 他のフィールドを初期化
}
public void init() { … }
…
class Y extends X {
public void init() {
// ここで this は未初期化
super.init();
}
…
}
❖未初期化のオブジェクトを識別したい
 未初期化のnullと意図的なnull値も区別したい
3
2011/06/29
提案手法
❖各バイトコードに Operational Semantics を定義
 各命令位置でのローカル変数，スタック，フィールドの状態を
求める
 各変数の値が他のどの変数の値と同じか，また null かどうか
 Path-sensitive, Interprocedural
❖各命令時点で変数に格納されているオブジェクトの
「未初期化フィールドの集合」を計算
 前段で求めた変数間の関係から，各命令位置での未初期
化フィールドの集合をグラフ表現に落とし，最小解を求める
 未初期化フィールドが1つでもあるオブジェクトを格納する変
数は @Raw とする
4
2011/06/29
評価実験
❖4つのソフトウェアに適用し既存ツールと比較
 @NonNull は94～98％ぐらい
 多いほどnon-nullと断定することに成功＝良い
 メソッドの仮引数，戻り値が対象
 @Rawは1%未満
 少ないほど未初期化でないと断定＝良い
 メソッドの呼び出し対象が @Raw であるものも検出
❖Plume という人間が @Nullable などのアノ
テーション付きコードと比較
 人間が間違っていた場所を数か所発見
5
2011/06/29
解析の特徴
❖Sound な静的解析
 Constraint Graph を解くところの正しさの議論は
別論文
 制御フローが複雑な場所は追い切れないことも
 @NonNull としないだけで，嘘の結果は出さない
❖読むときは……
 バイトコードの命令セットの知識が必要
 エイリアス解析など一般的なデータフロー解析系
の知識があれば比較的簡単な Semantics
6
2011/06/29
Taming Reflection:
Aiding Static Analysis in the Presence of
Reflection and Custom Class Loaders
❖著者： Eric Bodden, Andreas Sewe, Jan
Sinschek, Hela Oueslati, and Mira Mezini
❖提案手法： 実行時情報を使ってリフレクション
の振る舞いをプログラムに変換
 動的解析
 入力： Java バイトコード，実行テストケース1つ以上
 出力： リフレクションが実行する処理をコードとして
表現した Java バイトコードを出力
7
2011/06/29
研究の背景
❖静的解析では，リフレクションは難敵
 たとえば，動的解析のベンチマーク DaCapo で
は，main からリフレクションで色々な処理を起動
静的なコールグラフが役に立たない．
静的解析ツールから正しい結果を得られない．
❖リフレクションの文字列引数を静的に調べる
方法もあるが，リフレクションの引数は設定
ファイル等に依存することも多い
8
2011/06/29
提案手法
❖リフレクション呼び出しのログを取る
❖実行時に作られたクラスの内容を書き出しておく
 実行時に作られるクラスの名前は，中身のハッシュ値で正規化
❖リフレクションに対応する呼び出しをコードに追記
Connection c = new Connection();
Class clazz = Generator.makeClass(); // returns Foo$42
Method m = clazz.getMethod("foo", Connection.class);
m.invoke(null, c); // calls Foo$42.foo(..)
if (Opaque.false()) Foo$H1.foo(c);
else m.invoke(null, c); // 元の呼出し
条件節のOpaque.false()は
常にfalseを返すメソッド．
静的解析に Foo$H1.foo へ
の呼び出しを認識させる．
実行はelse節の
元の呼び出しを実行する．9
2011/06/29
評価実験
❖DaCapo のバイナリ＆実行ログを使用
 静的コールグラフの辺が 30本～3000本増加
 ベンチマークの設定（3通り）による実行トレースの変化
で，見つかる辺の数が20%程度変動（期待ほど大きくな
い）
 時間オーバーヘッド +10％程度．リフレクション多用した1
つだけ+100%
❖GUI アプリケーションを人間が操作して実験
 Eclipse や JEdit では，特定機能の実行で大幅に辺が増
える．本数は3000本程度
10
2011/06/29
解析の特徴
❖解析は Sound ではない
 けれども Sounder (本人談)
 動的解析なので，リフレクションの「代表的な動
作」をコード化している
 既存ツールの変更が不要というのがポイント
❖TAMIFLEX という名前で公開中
 http://tamiflex.googlecode.com/
 論文はツール実装の細かい戦略と実験がメイン
11
2011/06/29
Patching Vulnerabilities with
Sanitization Synthesis
❖著者: Fang Yu, Muath Alkhalaf, and Tevfik Bultan
❖提案手法： XSSやSQLインジェクションの問題検出，
修正方法の自動分析
 静的解析
 対象：PHP プログラム，攻撃パターン
 攻撃パターン ＝ printf や SQL 実行の引数としては不適切な文字
列の正規表現．
 たとえば HTML 出力時にスクリプトを出す可能性をチェックするに
は “ Σ* <SCRIPT Σ* ” と指定
 出力(1): 入力されるとまずい文字列の正規表現
 出力(2): 入力されるとまずい文字列を，安全な文字列にす
るために，どの文字（記号）を削除したらよいか提示
12
2011/06/29
提案手法 (1/2)
脆弱性の確認
❖文字列間の依存関係をグラフ化
❖オートマトンで取りうる文字列を計算
 攻撃パターンを指定
$name
$addr
Σ*
Σ*
 echo など出力命令に，
到達するとまずい文字列を指定
 ユーザからの入力は
Σ* （任意文字列）と仮定
 出力命令の引数が
攻撃パターンを満たすか
“Name: “ . $name .
“Address: “ . $addr
Name: Σ* Address: Σ*
echo
[攻撃パターン Σ* <SCRIPT 13
Σ*]
2011/06/29
提案手法 (2/2)
危険な入力の特定と，修正の提示
❖危険な文字列を構成しうる入力を求める
 例: $name . “Address: ” . $addr
 $name，$addr のそれぞれが “<SCRIPT” を含むと危険
 例： $name . $addr
 $name の終わりが “<SCR” で $addr の先頭が “IPT” と
いう場合でも危険，というところまで計算
 各入力変数の読み込み位置での条件を計算
❖受理状態への遷移を防ぐように，文字の削除
を開発者に提案
14
 例： $name, $addr それぞれからの “<” の削除
2011/06/29
評価実験
❖5つの既知の脆弱性を分析
 MyEasyMarket-4.1, BloggIT-1.0, proManager-0.72
 “<” を削除する，という最適解が出ることを示した
❖3つのOSSを解析
 Webchess 0.9.0, EVE 1.0, Faqforge 1.3.2
 サイズは最大で 3400 行
 解析時間 2分～5分，メモリは最大で140MB程度
 XSSの可能性 55個（うち2入力以上 11個）検出
 SQLI の可能性 60個（うち２入力以上 9個）検出
15
2011/06/29
解析の特徴
❖解析は Sound
 複数の入力から構成される文字列によって引き
起こされる脆弱性を扱えることが新しい
 文字列置換の操作にも対応
❖適用上の制限：攻撃パターンの指定が必要
 正規表現で書かなければいけない
 文字コードの数値などから作られる文字列もサ
ポートが明確ではない
16
2011/06/29