計算機言語論ＩＩSoftware Security

特に「安全メール」(2008 　 spring)

米澤明憲　

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

　

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

(Software Security) 研究で想定する脅威

• 悪意や誤りのあるプログラムが– 計算機システムを破壊– 秘密を漏洩

• コンピュータウィルスが– サーバプログラムの欠陥をついて侵入

• なりすまし（ impersonation ）– 正当な利用者のふりをして

計算機システムを不正使用、不正接続

セキュリティホールの原因

• 事故や攻撃に対する想定に漏れがある

– 最も一般的なセキュリティホールの原因は、　想定外の入力，想定外の環境やタイミングでの動

作などにより，システムが想定外の挙動を示す

E.g., 外部からワームやウイルスを注入される• E.g., 外部からのリクエストの組み合わせ次第

で，本来秘密の情報が漏れてしまう

よくある攻撃の例 : メールに添付されたウイルス

• 郵便受けは，外に向かって常に開いている• 通常のメールシステムは悪質な添付ファイ

ルの存在を想定していない– 「ユーザが判断できる」という逃げの姿勢で

設計されているシステムが多い

メール本文

添付ファイル(readme.exe)

従来手法 (1/3)

• 攻撃パターン毎に対症療法的に対応– E.g., パッチの配布– E.g., アンチウイルスソフト– E.g., ファイアウォール– E.g., 侵入検知システム (IDS)

既知の攻撃

未知の攻撃

正常

従来の対策法• 添付ファイルを開かないようにする• ワクチンで既知ウイルスを排除する

未知のウィルス・悪性プログラム

既知のウイルス

良性プログラム拒否　　　　　　　 　　　　　　　安全

有害なのに実行されてしまう

我々の不正コード防御戦略不正コード＝（ウイルスもその例）１．添付ファイル（コード）を理論の裏付けられた　　方法で解析し，危険性の有無を検査

２．危険性のある箇所は，安全なコードに書き換える

３．それができない場合， OS( あるいは

　 　 仮想機械）で監視しながら実行　　　　　　　　　　　　　　　　サンドボックス法

サンドボックス法（ Sandboxing）

環境

サンドボックス

システムリソース

サンドボックス内のアクセスは許可

サンドボックス外へのアクセスは禁止

ネットワーク

コード

資源アクセスの制御法1. システムコールフック2. バイナリーコード変換　 (課題： . 1 、 2 の利点・欠点の面で比較せよ .)

３．サンドボックス作るためのＯＳ組み込み機能

　 (Eg., 　 chroot – プロセスがアクセスできるファイル名空間を、全空間の 一部　　 である subtree に限定する。

　　　　　　 jail – ＦｒｅｅＢＳＤのシステムコールで、 Sbox をファイル＋ネットワーク　　 のアクセスも制限する。）

4. 　仮想機械や仮想ＯＳ5 ．サンドボックス処理の無効化・バイパス防止

我々の防御戦略３重のセーフティネットｰ

セキュアな言語の使用／実装

セキュアな実行時系・オペレーティングシステム

プログラムやプロトコルの論理的解析・検証

実行前

実行中

我々の防御網

無害化されたプログラム

既知のウイルス

拒否　　　　　　　

安全とわかるプログラム

監視実行されるプログラム

未知の不正コード( ウイルス）

この領域を我々の研究でできるだけ小さくする

　　　　　　　安全

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

データ B

バッファオーバーフロー (1/3)

• 指定されたメモリ領域からデータ溢れを起こすプログラミング上のバグ– 配列で宣言された範囲を超えたデータのアクセス

– 隣接したデータや制御情報を破壊– 普通は，ソフトウェアが異常終了– 不注意からバッファオーバーフローバグがプログラムに入り込むことが頻繁にある

• C言語の標準的な教科書（K&R）にもこのバグがデータ AA1 A2 A3 A4 A5 B1 B2 B3 B4A6 A7

バッファオーバーフロー (2/3)

• バッファオーバーフローを悪用した侵入法– 悪性命令列を含む長大なデータの送信

• 悪性命令列の設置＋命令制御情報の書き換え

データ Bデータ AA1 A2 A3 A4 A5次の命令 B2 B3 B4

もともとのプログラム

バッファオーバーフロー (3/3)

• バッファオーバーフローを悪用した侵入法– 悪性命令列を含む長大なデータの送信

– データとして悪性命令列をインストール– 命令制御情報の書き換えによって，制御を奪う

データ Bデータ A悪 い 命 令 列 B2 B3 B4次の命令

安全なメールシステム

インターネット

メールシステムの基本構造

サーバ

サーバメーラ

LAN

LAN

LAN

サーバ

メーラ

研究対象としてのメールシステム

• 問題が凝縮されている– サーバとクライアント

• サーバ：　公開アドレス，自律動作，ワームの脅威

• クライアント：　プライベートアドレス，人間が操作，　　　　　 　　　　　　　　　　　　　　　　　　　　ウイルスの脅威

– 信頼性に対する高い要求– 古典的問題

• 盗聴，改竄，なりすまし

想定するメールシステムへの攻撃

• サーバへの攻撃クラッキング，ワームサービス拒否攻撃

• 通信路への攻撃盗聴，改竄

• クライアントへの攻撃ウイルス添付メール迷惑メール

システムの安全性

• サーバ– ワームやクラッキングへの耐性– メーリングリストなど拡張機能の安全な実行– 故障時にはメールをどこかに退避

• メーラ– 添付ファイルの検査– 添付ファイルの安全な実行

• プロトコル– 配送経路のトラッキング– 送信否認の防止

23

基本的な 前提 (1/2)

• ハードウェア– 任意のタイミングで一時的に停止しうる– 頑強なストレージ（ミラーリング， RAID な

ど）を仮定–ハードウェアのセキュリティホールは想定外

• ネットワーク– 任意のタイミングで一時的に切断しうる

• システムソフトウェア– ＯＳ等のセキュリティホールは想定外

24

基本的な 前提 (2/2)

• 攻撃–ネットワーク経由の攻撃だけを仮定– 物理攻撃は想定外

• 互換性– 通常のメールシステムとの互換性が必要

我々のアプローチ (1/2)

• プログラムの検証と監視実行• 3階層のセーフティネット

セキュアな言語の使用実装

セキュアな実行時系・オペレーティングシステム

プログラムやプロトコルの検証

実行前

実行中

我々のアプローチ (2/2)悪性 良性

悪性と判定 良性と判定

監視実行

コード書換

サーバに対する脅威と対策

• ワームやクラッキング– バッファオーバーフロー攻撃などは，安全な

言語で防御• 危険な拡張機能

– SoftwarePot （加藤和彦）を用いて拡張機能を隔離実行

• メールの消失事故– 消失しないことを数学的に検証

• 証明は約 18,000 行• 証明支援系 Coq を利用

メーラに対する脅威とその対策

• 危険な添付ファイル– 検査系と実行系を　　　プラグイン可能にするシステム構成

を設計– 検査系：未知ウイルス検知システムなど– 実行系： SoftwarePot など

• 受信したメールの消失事故– 検証済み

主な要素技術 (1/2)

監視実行リソースの安全

性を保証

安全な言語メモリの安全性

を保証

プログラム検証耐故障性などを

保証

新規開発システム

主な要素技術 (2/2)

監視実行リソースの安全

性を保証

プログラム検証メモリの安全性

を保証

ダウンロードされたコード

プログラム検証の意義 (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

プログラム検証の意義 (2/2)

• 本当にクリティカルな部分は数学的検証を行う価値がある

• 我々の経験事例– コードサイズ 約 600 行– 証明サイズ 約 18,000 行– 労力 100～ 150人時

メールシステム構築の目的

• 安全なソフトウェアシステム構築方式を体系化– 想定する攻撃は，ワーム，ウイルス，クラッキン

グなど– ソフトウェア技術でソフトウェアを守る– 人的問題，社会的問題にはあまり踏み込まない– 暗号の問題にもあまり踏み込まない

• 領域に関連した技術の統合と実証試験• そのための例題としてメールシステムを選択

安全メールの基本機能

• 既存メールシステムとの互換性– SMTP/POP3 をサポート

• 安全サーバ– （機能的には普通の） SMTP サーバ

• 安全メーラ– MIME のサポート– Jar ファイルの実行環境

安全メールの特徴 (1/2)

• 安全プロトコル– 改竄防止と経路認証が可能な配送プロトコ

ル– 既存 SMTP サーバからは透過的– BAN 論理を用いた理論的な検証

• 安全サーバ– メモリセーフな実装– Coq を用いた形式的かつ機械的な検証

安全メールの特徴 (2/2)

• 安全メーラ– 検証するには複雑すぎる

• JavaMail, Java Swing などに依存– センシティブなのは添付ファイル実行部分– 検査器用のプラグインインタフェース

• E.g., 静的解析モジュール• E.g., コード変換モジュール• E.g., 動的モニタリングモジュール

– 実行器用のプラグインインタフェース

実装の状況

• Java 言語でメモリセーフに実装 • 基本機能と特徴的機能の一部が動作• Windows 2000/XP, Solaris 7/8, Linux,

MacOS X などで稼動 中• 現在 α版の段階

安全プロトコルの概要

• 改竄防止と経路認証– 改竄が行われていないことを確認できる– 送信者と 中継 サーバを確認できる– 送信を否認できない

• 信頼度の判断材料– E.g., 検査サーバが 中継 したメールは信頼する

• 匿名性での悪事も防ぎたい

危険サーバ

安全サーバ

安全プロトコルの実現

• 送信者と中継 サーバが電子署名– 中継 のたびに署名を追加

• 付加情報はヘッダーに格納– 送信者，送信先，時刻印，次のサーバ，署名など

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=

課題：　このプロトコルで安全でない部分を指摘し、その対策を考えよ。

安全プロトコルの検証

• ほぼ次のような性質を理論的に検証– 最終受信者は，メッセージ m を受信した時に，以下を確信できる

• 送信者が最初のサーバに m を送った• 経路上の各サーバ（最後のものは除く）が次

のサーバへ　 m を転送した

• 正確には，もっと複雑な性質を証明してる

安全プロトコルと相互運用性

• 配送経路上にレガシー SMTP サーバが存在する場合– メールの送受信は可能– 経路認証は部分的にしか機能しない– レガシーサーバが勝手にメールのボディを変更し

た場合，改竄とみなされる

• 暗号化，受信否認の防止などについて– 他のメッセージフォーマットやプロトコルと組み

合わる– SMTP 準拠なら組み合わせ可能

安全サーバの構成

• SMTP の送受信部，メッセージキュー管理部などから構成される，SMTPprotocol

SMTPprotocolSMTP

送信部SMTP受信部

署名メッセージキュー

安全サーバの検証 (1/3)

• SMTP 受信部の正当性を形式的に検証– プロトコル仕様を満たさないリクエストを拒否

する– 致命的エラー (fatal error) が生じない限り，プ

ロトコル仕様を満たすリクエストを受理する– Ack を返す前 に，メッセージをストレージに

セーブする（サーバが落ちてもメッセージは喪失されない）

SMTPprotocol

SMTP受信部

安全サーバの検証 (2/3)

• 証明支援系として　Coq を利用– Java のメソッドを Coq の関数へ変換して

から検証– オリジナルのプログラムからバグを数個発見

– 検証の規模とコスト• 対象は約 600 行の Java ソースコード• 仕様のサイズは約 300 行• 証明のサイズは約 5,000 行• 要した労力は，約 100人時＋ 2CPU 分

安全サーバの検証 (3/3)

• 検証を可能とした条件– 検証の対象が比較的小さかった– サーバの記述は，オブジェクト指向的でな

く，型安全な命令型– スレッド間の干渉が実質的にない

安全メーラ ( １ /2)

• 見かけは普通のメーラに近い– フォルダの一覧– 選択されたフォルダ内のメール一覧– 選択されたメールの内容表示

• MIME タイプに応じて，検証系と表示・実行系を選択– 検査系や表示・実行系はプラグイン可能

安全メーラ の見かけ

安全メーラの構成 (1/2)

• 検証系と実行系を追加できる

JVM

安全メーラJavaMail1.2

V1 V2 V3

V4

E1 E2 E3

E4検証モジュール

機能拡張モジュール

安全メーラの構成 (2/2)

安全メーラ

Java　Security　Architecture

E1 E2 E3 E4

V1 V2 V3 V4

A

A

外部検証器

安全

危険

OS　&　other　resources

添付コード

検証モジュール

外部検証＆実行モジュール

• 署名の検証系– Jar ファイルの署名を検査

• SoftwarePot– Linux/x86, Solaris のバイナリをサンドボックス内で実行

• 資源使用解析– 資源の利用順序に依存する性質を静的に検査

• アンチウイルスエンジン

まとめ

• 安全な配送プロトコルの設計と検証– 改竄と送信・転送の否認を防止

• サーバの構築と検証– シンプルな設計– コア部の検証

• クライアントの設計と構築– 本体の検証は当面行わない– 添付ファイルの安全な実行をめざす