1 / 51

計算機言語論ＩＩ Software Security 特に「安全メール」 (2008 spring) 米澤明憲

計算機言語論ＩＩ Software Security 特に「安全メール」 (2008 spring) 米澤明憲. 講義の概要. 0. 　参考文献など 「オブジェクト指向とは」とその他の雑談 ソフトウエアセキュリティの研究の一端 オブジェクト指向言語の特徴 オブジェクト指向の意味論・実装法 並列／分散オブジェクト指向計算 オブジェクト指向言語における「型」 （型付アセンブリ言語） （アスペクト指向プログラミング）. ソフトウエアセキュリティ研究の一端 （初心者向け）. (Software Security) 研究で 想定する脅威. 悪意や誤りのあるプログラムが

jermaine-burke
Download Presentation

計算機言語論ＩＩ Software Security 特に「安全メール」 (2008 spring) 米澤明憲

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. 計算機言語論ＩＩSoftware Security特に「安全メール」(2008spring)米澤明憲

  2. 講義の概要 0. 　参考文献など • 「オブジェクト指向とは」とその他の雑談 • ソフトウエアセキュリティの研究の一端 • オブジェクト指向言語の特徴 • オブジェクト指向の意味論・実装法 • 並列／分散オブジェクト指向計算 • オブジェクト指向言語における「型」 • （型付アセンブリ言語） • （アスペクト指向プログラミング）

  3. ソフトウエアセキュリティ研究の一端 （初心者向け）

  4. (Software Security)研究で想定する脅威 • 悪意や誤りのあるプログラムが • 計算機システムを破壊 • 秘密を漏洩 • コンピュータウィルスが • サーバプログラムの欠陥をついて侵入 • なりすまし（impersonation） • 正当な利用者のふりをして計算機システムを不正使用、不正接続

  5. セキュリティホールの原因 • 事故や攻撃に対する想定に漏れがある • 最も一般的なセキュリティホールの原因は、 　想定外の入力，想定外の環境やタイミングでの動作などにより，システムが想定外の挙動を示す E.g., 外部からワームやウイルスを注入される • E.g., 外部からのリクエストの組み合わせ次第で，本来秘密の情報が漏れてしまう

  6. 添付 ファイル (readme.exe) メール 本文 よくある攻撃の例: メールに添付されたウイルス • 郵便受けは，外に向かって常に開いている • 通常のメールシステムは悪質な添付ファイルの存在を想定していない • 「ユーザが判断できる」という逃げの姿勢で設計されているシステムが多い

  7. 従来手法 (1/3) • 攻撃パターン毎に対症療法的に対応 • E.g.,パッチの配布 • E.g.,アンチウイルスソフト • E.g.,ファイアウォール • E.g.,侵入検知システム(IDS) 正常 未知の攻撃 既知の 攻撃

  8. 従来の対策法 • 添付ファイルを開かないようにする • ワクチンで既知ウイルスを排除する 拒否　　　　　　　 　　　　　　　安全 既知の ウイルス 未知のウィルス・悪性プログラム 良性プログラム 有害なのに実行されてしまう

  9. 我々の不正コード防御戦略 不正コード＝（ウイルスもその例） １．添付ファイル（コード）を理論の裏付けられた 　　方法で解析し，危険性の有無を検査 ２．危険性のある箇所は，安全なコードに書き換える ３．それができない場合，OS(あるいは 仮想機械）で監視しながら実行 サンドボックス法

  10. サンドボックス法（Sandboxing） 環境 サンドボックス外への アクセスは禁止 サンドボックス システムリソース コード ネットワーク サンドボックス内の アクセスは許可

  11. 資源アクセスの制御法 • システムコールフック • バイナリーコード変換 (課題：. 1、2の利点・欠点の面で比較せよ.) ３．サンドボックス作るためのＯＳ組み込み機能 　(Eg.,chroot – プロセスがアクセスできるファイル名空間を、全空間の 一部　　 であるsubtreeに限定する。 jail – ＦｒｅｅＢＳＤのシステムコールで、Sboxをファイル＋ネットワーク　　 のアクセスも制限する。） 4.仮想機械や仮想ＯＳ 5．サンドボックス処理の無効化・バイパス防止

  12. 我々の防御戦略ｰ３重のセーフティネット プログラムやプロトコルの論理的解析・検証 実行前 セキュアな言語の使用／実装 実行中 セキュアな実行時系・ オペレーティングシステム

  13. 我々の防御網 拒否　　　　　　　 　　　　　　　安全 既知の ウイルス 未知の 不正コード (ウイルス） 無害化されたプログラム 安全とわかるプログラム 監視実行されるプログラム この領域を 我々の研究で できるだけ小さくする

  14. バッファーオーバフロー攻撃

  15. A1 A2 A3 A4 A5 A6 A7 B1 B2 B3 B4 バッファオーバーフロー (1/3) • 指定されたメモリ領域からデータ溢れを起こすプログラミング上のバグ • 配列で宣言された範囲を超えたデータのアクセス • 隣接したデータや制御情報を破壊 • 普通は，ソフトウェアが異常終了 • 不注意からバッファオーバーフローバグがプログラムに入り込むことが頻繁にある • C言語の標準的な教科書（K&R）にもこのバグが データB データA

  16. A1 A2 A3 A4 A5 バッファオーバーフロー (2/3) • バッファオーバーフローを悪用した侵入法 • 悪性命令列を含む長大なデータの送信 • 悪性命令列の設置＋命令制御情報の書き換え データA データB 次の命令 B2 B3 B4 もともとのプログラム

  17. 悪 い 命 令 列 バッファオーバーフロー (3/3) • バッファオーバーフローを悪用した侵入法 • 悪性命令列を含む長大なデータの送信 • データとして悪性命令列をインストール • 命令制御情報の書き換えによって，制御を奪う データA データB 次の命令 B2 B3 B4

  18. 安全なメールシステム

  19. インターネット メールシステムの基本構造 LAN LAN サーバ メーラ サーバ LAN サーバ メーラ

  20. 研究対象としてのメールシステム • 問題が凝縮されている • サーバとクライアント • サーバ：　公開アドレス，自律動作，ワームの脅威 • クライアント：　プライベートアドレス，人間が操作，　　　　　 　　　　　　　　　　　　　　　　　　　　ウイルスの脅威 • 信頼性に対する高い要求 • 古典的問題 • 盗聴，改竄，なりすまし

  21. 想定するメールシステムへの攻撃 • サーバへの攻撃 • クラッキング，ワーム • サービス拒否攻撃 • 通信路への攻撃 • 盗聴，改竄 • クライアントへの攻撃 • ウイルス添付メール • 迷惑メール

  22. システムの安全性 • サーバ • ワームやクラッキングへの耐性 • メーリングリストなど拡張機能の安全な実行 • 故障時にはメールをどこかに退避 • メーラ • 添付ファイルの検査 • 添付ファイルの安全な実行 • プロトコル • 配送経路のトラッキング • 送信否認の防止

  23. 基本的な前提 (1/2) • ハードウェア • 任意のタイミングで一時的に停止しうる • 頑強なストレージ（ミラーリング，RAIDなど）を仮定 • ハードウェアのセキュリティホールは想定外 • ネットワーク • 任意のタイミングで一時的に切断しうる • システムソフトウェア • ＯＳ等のセキュリティホールは想定外

  24. 基本的な前提 (2/2) • 攻撃 • ネットワーク経由の攻撃だけを仮定 • 物理攻撃は想定外 • 互換性 • 通常のメールシステムとの互換性が必要

  25. 我々のアプローチ (1/2) • プログラムの検証と監視実行 • 3階層のセーフティネット プログラムやプロトコルの検証 実行前 セキュアな言語の使用実装 実行中 セキュアな実行時系・ オペレーティングシステム

  26. 我々のアプローチ (2/2) 悪性 良性 コード書換 監視実行 悪性と判定 良性と判定

  27. サーバに対する脅威と対策 • ワームやクラッキング • バッファオーバーフロー攻撃などは，安全な言語で防御 • 危険な拡張機能 • SoftwarePot （加藤和彦）を用いて 拡張機能を隔離実行 • メールの消失事故 • 消失しないことを数学的に検証 • 証明は約18,000行 • 証明支援系 Coq を利用

  28. メーラに対する脅威とその対策 • 危険な添付ファイル • 検査系と実行系を 　　　プラグイン可能にするシステム構成を設計 • 検査系：未知ウイルス検知システムなど • 実行系：SoftwarePotなど • 受信したメールの消失事故 • 検証済み

  29. 安全な言語 メモリの安全性を保証 監視実行 リソースの安全性を保証 主な要素技術 (1/2) プログラム検証 耐故障性などを保証 新規開発 システム

  30. プログラム検証 メモリの安全性を保証 監視実行 リソースの安全性を保証 主な要素技術 (2/2) ダウンロード されたコード

  31. プログラム検証の意義 (1/2) • Common Criteria Evaluation Assurance Levels • EAL1: Functionally Tested • EAL2: Structurally Tested • EAL3: Methodically Tested and Checked • EAL4: Methodically Designed, Tested, and Reviewed • EAL5: Semiformally Designed and Tested • EAL6: Semiformally Verified Design and Tested • EAL7: Formally Verified Design and Tested

  32. プログラム検証の意義 (2/2) • 本当にクリティカルな部分は数学的検証を行う価値がある • 我々の経験事例 • コードサイズ 約600行 • 証明サイズ 約18,000行 • 労力 100～150人時

  33. メールシステム構築の目的 • 安全なソフトウェアシステム構築方式を体系化 • 想定する攻撃は，ワーム，ウイルス，クラッキングなど • ソフトウェア技術でソフトウェアを守る • 人的問題，社会的問題にはあまり踏み込まない • 暗号の問題にもあまり踏み込まない • 領域に関連した技術の統合と実証試験 • そのための例題としてメールシステムを選択

  34. 安全メールの基本機能 • 既存メールシステムとの互換性 • SMTP/POP3 をサポート • 安全サーバ • （機能的には普通の） SMTPサーバ • 安全メーラ • MIMEのサポート • Jar ファイルの実行環境

  35. 安全メールの特徴 (1/2) • 安全プロトコル • 改竄防止と経路認証が可能な配送プロトコル • 既存 SMTPサーバからは透過的 • BAN論理を用いた理論的な検証 • 安全サーバ • メモリセーフな実装 • Coq を用いた形式的かつ機械的な検証

  36. 安全メールの特徴 (2/2) • 安全メーラ • 検証するには複雑すぎる • JavaMail, Java Swingなどに依存 • センシティブなのは添付ファイル実行部分 • 検査器用のプラグインインタフェース • E.g.,静的解析モジュール • E.g., コード変換モジュール • E.g.,動的モニタリングモジュール • 実行器用のプラグインインタフェース

  37. 実装の状況 • Java 言語でメモリセーフに実装 • 基本機能と特徴的機能の一部が動作 • Windows 2000/XP, Solaris 7/8, Linux, MacOS Xなどで稼動中 • 現在α版の段階

  38. 安全プロトコルの概要 • 改竄防止と経路認証 • 改竄が行われていないことを確認できる • 送信者と中継サーバを確認できる • 送信を否認できない • 信頼度の判断材料 • E.g.,検査サーバが中継したメールは信頼する • 匿名性での悪事も防ぎたい 安全 サーバ 危険 サーバ

  39. 安全プロトコルの実現 • 送信者と中継サーバが電子署名 • 中継のたびに署名を追加 • 付加情報はヘッダーに格納 • 送信者，送信先，時刻印，次のサーバ，署名など X-Anz: fm=etsuya@is.titech.ac.jp,to=takuo@cs.titech.ac.jp:.. X-Anz-Sig: sn=0,si=anzenmail.is.titech.ac.jp,di=cs.titech.ac.jp, 　　ts=1026375710449,sa=SHA1withRSA,sg=xLsXLKk+T1P　　　l7DxacE1DgWZAQffJ07wQ9sn8luUQZvqlAFOVBD9CP　　　wZxOP5uJ6nHtQ4y74loMpMokhgfzjdWzafEQzAUMwD　　9PBLQK9hlL2v+6xpFdca9pht7OSsLsTzb0BVihZmX666　　　F93kadO95ceLonKJDEJKAyOGUZ/ll5Eo= 課題：　このプロトコルで安全でない部分を指摘し、その対策を考えよ。

  40. 安全プロトコルの検証 • ほぼ次のような性質を理論的に検証 • 最終受信者は，メッセージ mを受信した時に，以下を確信できる • 送信者が最初のサーバに mを送った • 経路上の各サーバ（最後のものは除く）が次のサーバへ　mを転送した • 正確には，もっと複雑な性質を証明してる

  41. 安全プロトコルと相互運用性 • 配送経路上にレガシー SMTP サーバが存在する場合 • メールの送受信は可能 • 経路認証は部分的にしか機能しない • レガシーサーバが勝手にメールのボディを変更した場合，改竄とみなされる • 暗号化，受信否認の防止などについて • 他のメッセージフォーマットやプロトコルと組み合わる • SMTP 準拠なら組み合わせ可能

  42. 安全サーバの構成 • SMTPの送受信部，メッセージキュー管理部などから構成される， SMTP protocol SMTP protocol SMTP 受信部 SMTP 送信部 メッセージキュー 署名

  43. 安全サーバの検証 (1/3) • SMTP 受信部の正当性を形式的に検証 • プロトコル仕様を満たさないリクエストを拒否する • 致命的エラー(fatal error)が生じない限り，プロトコル仕様を満たすリクエストを受理する • Ackを返す前に，メッセージをストレージにセーブする（サーバが落ちてもメッセージは喪失されない） SMTP 受信部 SMTP protocol

  44. 安全サーバの検証 (2/3) • 証明支援系としてCoqを利用 • Javaのメソッドを Coqの関数へ変換してから検証 • オリジナルのプログラムからバグを数個発見 • 検証の規模とコスト • 対象は約600行のJavaソースコード • 仕様のサイズは約300行 • 証明のサイズは約5,000行 • 要した労力は，約100人時＋2CPU分

  45. 安全サーバの検証 (3/3) • 検証を可能とした条件 • 検証の対象が比較的小さかった • サーバの記述は，オブジェクト指向的でなく，型安全な命令型 • スレッド間の干渉が実質的にない

  46. 安全メーラ (１/2) • 見かけは普通のメーラに近い • フォルダの一覧 • 選択されたフォルダ内のメール一覧 • 選択されたメールの内容表示 • MIMEタイプに応じて，検証系と表示・実行系を選択 • 検査系や表示・実行系はプラグイン可能

  47. 安全メーラ の見かけ

  48. 安全メーラの構成 (1/2) • 検証系と実行系を追加できる 検証 モジュール 機能拡張 モジュール V4 E4 V1 V2 V3 E1 E2 E3 安全メーラ JavaMail1.2 JVM

  49. 安全メーラの構成 (2/2) 検証 モジュール 外部 検証器 危険 V1 V2 V3 V4 安全 A E1 E2 E3 E4 安全メーラ A 添付コード Java Security Architecture OS & other resources

  50. 外部検証＆実行モジュール • 署名の検証系 • Jar ファイルの署名を検査 • SoftwarePot • Linux/x86, Solarisのバイナリをサンドボックス内で実行 • 資源使用解析 • 資源の利用順序に依存する性質を静的に検査 • アンチウイルスエンジン

More Related