セキュリティ機構の開発と評価のための異常注入システム

1. セキュリティ機構の開発と評価のための異常注入システムセキュリティ機構の開発と評価のための異常注入システム 大山 恵弘 電気通信大学

2. 背景 • コンピュータシステムへの攻撃の脅威は依然として大きい • その対策として、多くのセキュリティシステムが研究、開発されている • しかし、セキュリティシステムの開発やテストには手間がかかる

3. セキュリティシステムの開発者が直面する問題セキュリティシステムの開発者が直面する問題 • 作ったシステムのテストや評価が面倒 典型的な作業の流れ： • 脆弱性を持つプログラムを準備する • 脆弱性を突く攻撃コードを書く • 自分のシステムがその攻撃を検出や防御できたかを調べる

4. 脆弱性を持つプログラムの準備の仕方いろいろ脆弱性を持つプログラムの準備の仕方いろいろ • 脆弱性情報などをもとに脆弱性を持つソフトウェアを探して拾ってくる • 探すのが面倒 • 拾ってきたソフトウェアのバージョンは古くなりがち • 自分で脆弱なプログラムを書く • トイプログラムになりがち • 人工的な脆弱性を含ませる改造を施す • 改造は面倒であり、スキルも必要 • ソースコードが必要

5. 動機 • 攻撃を受けたときに何が起こるかを、任意のアプリケーションに対して調べたい • 特に、セキュリティ機構が作動するかどうかを調べたい • アプリケーションには現在脆弱性が発見されていないものとする • もし脆弱性があって、もし乗っ取られたら、何が起こるかを見たい • 雑に言えば、攻撃被害のインスタンスを（多少人工的でもいいので）大量生産したい

6. 本研究の目的 • 攻撃注入システムHyperAttackerの構築 • プログラムのメモリ内容を書き換え、攻撃されたかのような効果を人工的に作り出す • 脆弱性がないプログラムに、外部から異常を注入 • ユーザは異常注入に関するシナリオを記述

7. 実装戦略 • ソースコードの変換 • アスペクト指向ツールの利用 • アプリケーションプロセスのアドレス空間上のデータを、外の何者かが更新 • 仮想マシンモニタが更新 • 他のプロセスが更新 長期的に 目指したいもの 本研究で実装した プロトタイプ

8. HyperAttackerプロトタイプの構造 シナリオ 操作 攻撃効果 監視 アプリケーション プロセス HyperAttacker プロセス OS

9. HyperAttackerでできること • プログラムがある実行状態になった時に、あるメモリ領域にデータを書き込む • 現在、実行状態として表現可能なもの： • 関数の先頭/末尾 • 関数Aの中での関数Bの呼び出し直前/直後 read_input() { … strcpy(…); … }

10. HyperAttackerでできることの例 • 関数read_inputからのstrcpyの1000回目の呼び出し直後に、指定のバイト列を現在のスタックフレームに書き込む • 関数parse_dataの先頭に来た時に、0.003の確率で、指定の長さのランダムバイト列をバッファbufに書き込む • 関数copy_bufferからの最初の復帰で、関数delete_passwordのアドレスを、リターンアドレス領域に書き込む

11. シナリオ例１ • 関数read_inputからのstrcpyの1000回目の呼び出し直後に、指定のバイト列を現在のスタックフレームに書き込む condition: after strcpy in read_input numcalled=1000 manipulation: sp <- bytes 10 ab97cd

12. シナリオ例２ • 関数parse_dataの先頭に来た時に、0.003の確率で、200バイトのランダムバイト列をバッファbufに書き込む condition: head in parse_data possibility=0.003 manipulation: varbuf <- randbytes 200

13. シナリオ例３ • 関数copy_bufferからの最初の復帰で、関数delete_passwordのアドレスを、リターンアドレス領域に書き込む condition: tail in copy_buffer numcalled=1 manipulation: retaddr <- varaddrdelete_password

14. 実装 • ptraceシステムコールを利用 • HyperAttacker （親）プロセスがアプリケーション（子）プロセスの動作を追跡 • 子のシグナル受信、実行終了、システムコール呼び出しなどを検知 • ブレークポイントを利用 • ptraceにより、シナリオで指定されたプログラムポイントにブレークポイントを挿入 • アプリケーションが指定の場所に到達したことを検知

15. アプリケーションのコード領域へのブレークポイントの挿入アプリケーションのコード領域へのブレークポイントの挿入 • 関数の先頭/末尾のコードアドレスを得る • 実行型およびオブジェクトファイルが貼り付けられた領域のアドレスを/procから得る • 領域内の関数のオフセットをobjdumpコマンドで得る • 指定の関数内のcall命令の情報を得る • objdumpコマンドで逆アセンブルする • ptraceにより、得られたアドレスの内容を0xccで上書きする

16. 異常の注入処理 • シナリオに沿って子プロセスのメモリの内容を更新 • ptraceを利用 • データを書き込める場所 • 大域変数のあるアドレスから始まる領域 • スタックポインタが指すアドレスから始まる領域 • 現在のスタックフレームのリターンアドレス領域

17. fork 監視 アプリケーション プロセス HyperAttacker プロセス fork fork 監視 アプリケーション プロセス HyperAttacker プロセス

18. exec progA用 シナリオ 監視 progA progB HyperAttacker プロセス progB用 シナリオ

19. コードに関する細かい事項 • 対象プラットフォーム: Linux/x86 • コードサイズ • HyperAttacker本体:Cで約1000行 • プロセス監視ライブラリPROMON:Cで約1400行

20. 実験１ • Webサーバthttpに異常を注入 • GCCのStack-Smashing Protector (SSP) を有効にしてthttpdをビルド • StackGuardに似た機構 • 関数send_response_tail内のmy_snprintfの最初の呼び出し直後にスタックを破壊 • SSPによって安全に実行が停止することを確認

21. thttpdのソースコードの抜粋 static voidsend_response_tail( httpd_conn* hc ) { char buf[1000]; (void) my_snprintf( buf, sizeof(buf), "\ <HR>\n\ <ADDRESS><A HREF=\"%s\">%s</A></ADDRESS>\n\ </BODY>\n\ </HTML>\n", SERVER_ADDRESS, EXPOSED_SERVER_SOFTWARE ); add_response( hc, buf ); }

22. thttpdに異常を注入するシナリオ condition: after my_snprintf in send_response_tail numcalled=1 manipulation: sp <- randbytes 2000

23. 実験２ • WebブラウザFirefoxに異常を注入 • 配布バイナリ内にはシンボル情報はないが、ライブラリ境界に異常を注入可能 • strcpyを一定数実行したらspが指す領域にランダムバイト列を書き込むなどの実験を実施

24. 一つのアナロジ • HyperAttacker ＝ 避難訓練システム • 火事がない建物に疑似的な火事を発生させる • 30年地震がない地域に大地震を発生させる • どの時間にどの場所でどういう災害が発生するかのシナリオは人間が明確に定める • 避難訓練は安全性の向上に不可欠

25. 議論（１） • なぜアスペクト指向を使わないのか？→ アプリを再ビルドしたくない→ ソースを持っていないアプリに異常を注入したいこともある • マルチスレッドアプリケーションには対応している？→ 対応していません

26. 議論（２） • ptraceベースのセキュリティシステムと衝突するのではないのか？→ はい、衝突します→ だから将来はVMM層で実現したい • シンボル情報をstripしたバイナリに異常を注入できるか？→ stripされたシンボルの関数にまつわる地点での異常注入はできません→ 動的リンクライブラリの呼び出し前後での異常注入はできます

27. オーバヘッド • 大きく分けて2つ • コンテキストスイッチ • システムコールを呼び出したとき • ブレークポイントを踏んだとき • シグナルを受信したとき • 異常注入のためのメモリ内容の読み出しと更新 • システムコールフックのみのオーバヘッドは経験的には、100%程度 • ブレークポイント通過や異常注入のオーバヘッドはシナリオによって大きく変動

28. 関連研究 • Software-implemented fault injection (SWIFI) • Xception [Carreira et al. ’98] • カーネルモジュールを用いた障害注入システム • 扱われているのは主にハードウェア障害 • アドレスバス、浮動小数ユニットなど • FIG [Broadwell et al. ’01] • ライブラリ置き換えにより障害を発生させるシステム • 障害はライブラリ関数の返り値の異常に限られる • [Le et al. ’08] • VMMを用いた障害注入システム • 障害はメモリの内容を1bit反転するなどの単純なものに限られる

29. まとめ • 脆弱性も攻撃もないプログラム内に、攻撃された効果を作るシステムを提案した • 本システムはセキュリティ機構が正しく動作するかを検査するのに有用である

30. 今後の課題 • VMM層でのHyperAttackerの実現 • ptrace衝突問題を解決する • カーネル空間への異常注入も可能になる • シナリオ言語の洗練 • より複雑な条件やメモリ内容更新操作が書けるようにする • 局所変数が指す領域やレジスタにもデータを注入できるようにしたい • 条件に書く関数、注入される領域、注入するデータの部分にも乱数性を入れたい