1 / 16

Program Surfing I プログラム解析いろいろ

Program Surfing I プログラム解析いろいろ. Inference of Field Initialization 未初期化オブジェクトの使用を推論 Taming Reflection リフレクションを通常のコードに変換する動的解析 Patching Vulnerabilities with Sanitization Synthesis XSS などを引き起こす入力文字列の自動特定. 石尾 隆 ishio@ist.osaka-u.ac.jp. Inference of Field Initialization.

dean-rice
Download Presentation

Program Surfing I プログラム解析いろいろ

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Program Surfing Iプログラム解析いろいろ • Inferenceof Field Initialization • 未初期化オブジェクトの使用を推論 • Taming Reflection • リフレクションを通常のコードに変換する動的解析 • Patching Vulnerabilities with Sanitization Synthesis • XSSなどを引き起こす入力文字列の自動特定 石尾 隆 ishio@ist.osaka-u.ac.jp

  2. Inference of Field Initialization • 著者：FaustoSpoto and Michael D. Ernst • 提案手法： プログラムの各時点で，オブジェクトのフィールドが初期化されているか推論 • 静的解析 • Java バイトコードを解析 • オブジェクト型の変数について以下の情報を出力 • null でないことが保障されるか否か（@NonNull） • フィールドに未初期化のものがあるか（@Raw）

  3. 研究の背景 • 未初期化のフィールドを知らずに使ってしまうと，間違いのもとになる • 未初期化のオブジェクトを識別したい • 未初期化のnullと意図的なnull値も区別したい class Y extends X { public void init() { // ここで this は未初期化 super.init(); } … } class X { public X() { this.field = 0; // フィールド初期化 init(); // 他のフィールドを初期化 } public void init() { … } …

  4. 提案手法 • 各バイトコードにOperational Semantics を定義 • 各命令位置でのローカル変数，スタック，フィールドの状態を求める • 各変数の値が他のどの変数の値と同じか，また null かどうか • Path-sensitive, Interprocedural • 各命令時点で変数に格納されているオブジェクトの「未初期化フィールドの集合」を計算 • 前段で求めた変数間の関係から，各命令位置での未初期化フィールドの集合をグラフ表現に落とし，最小解を求める • 未初期化フィールドが1つでもあるオブジェクトを格納する変数は @Raw とする

  5. 評価実験 • 4つのソフトウェアに適用し既存ツールと比較 • @NonNullは94～98％ぐらい • 多いほどnon-nullと断定することに成功＝良い • メソッドの仮引数，戻り値が対象 • @Rawは1%未満 • 少ないほど未初期化でないと断定＝良い • メソッドの呼び出し対象が @Raw であるものも検出 • Plume という人間が @Nullableなどのアノテーション付きコードと比較 • 人間が間違っていた場所を数か所発見

  6. 解析の特徴 • Sound な静的解析 • Constraint Graph を解くところの正しさの議論は別論文 • 制御フローが複雑な場所は追い切れないことも • @NonNull としないだけで，嘘の結果は出さない • 読むときは…… • バイトコードの命令セットの知識が必要 • エイリアス解析など一般的なデータフロー解析系の知識があれば比較的簡単な Semantics

  7. Taming Reflection:Aiding Static Analysis in the Presence of Reflection and Custom Class Loaders • 著者： Eric Bodden, Andreas Sewe, Jan Sinschek, HelaOueslati, and Mira Mezini • 提案手法： 実行時情報を使ってリフレクションの振る舞いをプログラムに変換 • 動的解析 • 入力： Java バイトコード，実行テストケース1つ以上 • 出力： リフレクションが実行する処理をコードとして表現した Java バイトコードを出力

  8. 研究の背景 • 静的解析では，リフレクションは難敵 • たとえば，動的解析のベンチマーク DaCapoでは，main からリフレクションで色々な処理を起動 • 静的なコールグラフが役に立たない． • 静的解析ツールから正しい結果を得られない． • リフレクションの文字列引数を静的に調べる方法もあるが，リフレクションの引数は設定ファイル等に依存することも多い

  9. 提案手法 • リフレクション呼び出しのログを取る • 実行時に作られたクラスの内容を書き出しておく • 実行時に作られるクラスの名前は，中身のハッシュ値で正規化 • リフレクションに対応する呼び出しをコードに追記 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(..) 条件節のOpaque.false()は常にfalseを返すメソッド． 静的解析に Foo$H1.fooへの呼び出しを認識させる． 実行はelse節の 元の呼び出しを実行する． if (Opaque.false()) Foo$H1.foo(c); else m.invoke(null, c); // 元の呼出し

  10. 評価実験 • DaCapo のバイナリ＆実行ログを使用 • 静的コールグラフの辺が 30本～3000本増加 • ベンチマークの設定（3通り）による実行トレースの変化で，見つかる辺の数が20%程度変動（期待ほど大きくない） • 時間オーバーヘッド+10％程度．リフレクション多用した1つだけ+100% • GUI アプリケーションを人間が操作して実験 • Eclipse や JEditでは，特定機能の実行で大幅に辺が増える．本数は3000本程度

  11. 解析の特徴 • 解析は Sound ではない • けれども Sounder (本人談) • 動的解析なので，リフレクションの「代表的な動作」をコード化している • 既存ツールの変更が不要というのがポイント • TAMIFLEX という名前で公開中 • http://tamiflex.googlecode.com/ • 論文はツール実装の細かい戦略と実験がメイン

  12. Patching Vulnerabilities with Sanitization Synthesis • 著者: Fang Yu, MuathAlkhalaf, and TevfikBultan • 提案手法： XSSやSQLインジェクションの問題検出，修正方法の自動分析 • 静的解析 • 対象：PHP プログラム，攻撃パターン • 攻撃パターン ＝ printfや SQL 実行の引数としては不適切な文字列の正規表現． • たとえば HTML 出力時にスクリプトを出す可能性をチェックするには “Σ* <SCRIPTΣ* ”と指定 • 出力(1): 入力されるとまずい文字列の正規表現 • 出力(2): 入力されるとまずい文字列を，安全な文字列にするために，どの文字（記号）を削除したらよいか提示

  13. 提案手法 (1/2) 脆弱性の確認 • 文字列間の依存関係をグラフ化 • オートマトンで取りうる文字列を計算 • 攻撃パターンを指定 • echo など出力命令に， 　到達するとまずい文字列を指定 • ユーザからの入力は Σ* （任意文字列）と仮定 • 出力命令の引数が 攻撃パターンを満たすか $addr Σ* $name Σ* “Name: “ . $name . “Address: “ . $addr Name: Σ* Address: Σ* echo [攻撃パターン Σ* <SCRIPT Σ*]

  14. 提案手法 (2/2)危険な入力の特定と，修正の提示 • 危険な文字列を構成しうる入力を求める • 例: $name . “Address: ” . $addr • $name，$addrのそれぞれが “<SCRIPT” を含むと危険 • 例： $name . $addr • $name の終わりが “<SCR” で $addrの先頭が “IPT” という場合でも危険，というところまで計算 • 各入力変数の読み込み位置での条件を計算 • 受理状態への遷移を防ぐように，文字の削除を開発者に提案 • 例： $name, $addrそれぞれからの “<” の削除

  15. 評価実験 • 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個）検出

  16. 解析の特徴 • 解析は Sound • 複数の入力から構成される文字列によって引き起こされる脆弱性を扱えることが新しい • 文字列置換の操作にも対応 • 適用上の制限：攻撃パターンの指定が必要 • 正規表現で書かなければいけない • 文字コードの数値などから作られる文字列もサポートが明確ではない

More Related