プロフィール

大山恵弘

  • Author:大山恵弘
  • 公式なサイトはこちら

最近の記事

最近のコメント

最近のトラックバック

月別アーカイブ

ブロとも申請フォーム

ブログ内検索

RSSフィード

リンク

FC2カウンター

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

【ソフトウェア工学】 Highly Reliable Upgrading of Components 【プログラミング言語】

In ICSE '99.
http://www.cs.nmsu.edu/~jcook/papers/

コンポーネントをアップグレードしても信頼性を失わせないための技法。

コンポーネントをアップグレードしても古いコンポーネントは消さない。そのコンポーネントが呼び出されたら、新しいコンポーネントも、過去のコンポーネント群も実行。プロキシみたいなプログラム(Arbeiter)がコンポーネント群のインタフェースをメインプログラムへ提供する役を果たす。メインプログラムは一つの普通のコンポーネントだと思って呼び出す。Arbeiterが複数モジュールから結果を受け取ったら、一つを選んで返す。各バージョンがどんな結果を返したかを解析。

どういうコンポーネントが信頼できるかについての仕様を、制約?で指示。特定の呼び出しに対して、どのバージョンが正しい結果を返すかを求める。各バージョンが正しい結果を返す回数を数え、どんな呼び出しについてはどのバージョンが信頼できるかを判断。最も信頼できるコンポーネントによる実行結果を返すとか、危ないコンポーネントは実行しないなどの制御ができる。
スポンサーサイト

【異常検知】 Artemis: Practical Runtime Monitoring of Applications for Errors 【instrument】

Purdue University TR-ECE 05-02
https://engineering.purdue.edu/ECE/Research/TR/2005.whtml

異常検知などのためにプログラム監視用に挿入されたinstrumentのオーバヘッドを削減するための枠組みの提案。シングルスレッドCプログラム用。

各手続きについて、instrumentを入れたバージョンと、instrumentを入れないバージョンの2つを用意。異常をできるだけ見逃さないようにしながら、できるだけinstrumentを入れないバージョンを実行したいってのが動機。

方法。まずプログラムを訓練モードで実行して、各関数が呼び出されるときの実行コンテキストについてのinvariantを作る。後にプロダクションモードで実行。実行コンテキストは、すべてのスコープ内変数、手続きのパラメタ、それらから辿れるデータすべてによって表現。

関数を呼び出した際には、呼び出し時の実行コンテキストが、訓練モードで作られたinvariantを満たしているかどうか検査。満たしている場合には、その関数の実行には、instrumentを入れてないコードを使う。満たしていない場合には、instrumentを入れたコードを使う。

背後にある観察は、関数呼び出し時の実行コンテキストが同じで、かつ、シングルスレッドならば、その関数は決定的に、訓練モードと同じように実行される可能性が高い、というもの。

筑波大時代にDIDUCEの論文読んでショック受けました。で、これはDIDUCEに引き続く研究。DIDUCE的手法の適用先として、instrumentのオーバヘッド削減ていう目新しいものをもってきたってところが、この研究のポイントか。つい、この手の研究では、異常検知の精度を上げるだのオーバヘッドを減らすだのって方向に行ってしまいがち。別の方向を向いて、Artemisは異常検知のための技法ではない、って位置づけてるあたりのやり方がうまいかも。

過去の挙動の学習に基づく異常検知についての論文は、このへんとかこのへんにもあります。

【セキュリティ】 Secure Program Execution via Dynamic Information Flow Tracking 【情報流解析】

In ASPLOS 2004.
http://csg.csail.mit.edu/pubs/publications.html

情報流追跡をハードウェアでやって不正コードの実行を防止するアプローチの提案。

情報流追跡機能を有するプロセッサを使う。外から入ってくるデータにOSがタグづけする。そのデータからの情報流をプロセッサが自動追跡。外からのデータに由来するデータを命令として実行したり、そういうデータをジャンプ先として使用しようとしたら、プロセッサが例外を発生させる。

情報流解析+バッファオーバフロー+新プロセッサのトリポッドってとこですか。奇をてらわず王道的な感じの論文。確実に仕事してますって感じ。

セキュリティまわりで自分が考えてきた色々なネタを、新しいハードウェアを提案することも視野に入れて見直してみると、いいことありそうな気がしてきた。

【セキュリティ】 Hiding Software Slices for Software Security 【プログラミング言語】

In CGO 2003.
http://www.cgo.org/cgo2003/

ソフトウェアパイラシーに対処する手法の提案。
プログラムを二つの部分に分割する。
片方を公開して、信頼できない計算機で実行する。盗まれてもよい。
片方は公開せず、安全な計算機で実行する。

プログラムを分割するためのアルゴリズムを示し、
5つのJavaプログラムに適用して有効性を評価した。

この手のプログラム分割ネタは好きです。

MeyerさんやSongさんによる、安全な実行のためのプログラム分割に
方向が似ているような気がするが、論文中では特に比較はされていないようだ。
ていうかアイデア自体は結構スタンダードな気がするんですがどうなんでしょう。
90年代終わりのメタコンピューティングの研究にも関連研究が結構ありそう。

プログラム分割をセキュリティシステムに適用した研究が
このへんにあります。

Polygraph: Automatically Generating Signatures for Polymorphic Worms

In IEEE S&P 2005.
http://www.ece.cmu.edu/~jnewsome/

多相型ウィルスにマッチするシグネチャを自動生成する方式の提案。
特徴は、多相型ウィルスのシグネチャを複数のバイト列で表現すること。
多相型ウィルスの中には、そのウィルスを特徴づけるバイト列が
ところどころに、必ずしも連続せず出現するので、それらをマッチ・検出する。

シグネチャを単一固定バイト列以外(たとえば正規表現とか)で表現できるIDSはすでにある。Snortもそう。
本研究の貢献は、そういうシグネチャを自動生成するって部分みたい。

中見ると文字列マッチングみたいな話とかベイズ分類の話とか。

【セキュリティ】 An Email Worm Vaccine Architecture 【VM】

In ISPEC 2005.
http://www1.cs.columbia.edu/~angelos/cv.html

悪意の添付ファイルを持つメールをMTAが自動的にフィルタするアーキテクチャの提案。

MTAが添付ファイルを検出したら、それをVMの中で実行する。あやしい動きをしたら、そのメールをドロップする。クラスタ上に、添付ファイル実行用のVMをたくさん作って、並列にVMを実行して、高いメール負荷にも対応できるようにする。VM作成にはVMwareを使っている。

実行された添付ファイルが悪意か悪意でないかは、RADという侵入検知システムを利用して判断する。RADはWindowsレジストリアクセスの情報を利用して侵入検知する。

実験では、悪意の添付ファイルをすべて検出することができた。誤陽性率は5%以下におさえられた。

このプロジェクトでも、悪意コードをVM上で動かすなどの応用を考えています。

【セキュリティ】 Automatic Generation of Buffer Overflow Attack Signatures: An Approach Based on Program Behavior Models 【IDS】

In ACSAC 2005.
http://www.acsa-admin.org/2005/abstracts/140.html

攻撃があった時付近のサーバへの入力の特徴と、平常時のサーバへの入力の特徴を比較。
攻撃と考えられる入力から自動的に攻撃シグネチャを合成する。
以降の実行ではそのシグネチャを含む入力をフィルタする。
攻撃の特徴としては、入力の長さ、バイナリデータの有無を用いる。
シグネチャの精度を高めるためにプログラムのコンテキスト情報を用いる。

彼らのUSENIX Annual 2005の論文の内容にちょっと似てるかな。

【セキュリティ】 e-NeXSh: Achieving an Effectively Non-Executable Stack and Heap via System-Call Policing 【システムコール・スタック検査】

In ACSAC 2005.
http://www.acsa-admin.org/2005/abstracts/103.html

プロセス乗っ取り攻撃を防御する手法の提案。

すべてのlibc関数呼び出しとシステムコール呼び出しを監視する。カーネルの修正と共有ライブラリによって実現。

libc関数が呼び出されたときに、正しい呼び出し履歴になっているかどうか、プロセスのスタックのコールチェインを検査。システムコールが呼び出されたときに、それが正しい場所から呼び出されているかどうかを検査。

プログラムバイナリとその逆アセンブル結果を利用。

かなりオーソドックスな手法に見える。今までに提案されていなかったのかなと思ったが、提案されていないのかもしれない。もしくは実験で示された高い有用性が評価されたか。もちろん関連研究は山のようにありそう。

システムコールが呼び出されたときに、プロセスのスタックの呼び出し履歴を検査して攻撃を検出する他の研究としては、これとかこれがあります。

【セキュリティ】 WORM vs. WORM: Preliminary Study of an Active Counter-Attack Mechanism 【ワーム】

In WORM '04.
http://www.icir.org/vern/worm04/

ワームのデータを変換して、そのワームを除去するための「アンチワーム」を自動生成する手法の提案。アンチワームは、対応するワームが感染しているホストからそのワームを除去してホストを正常な状態に戻す。Codered, Blaster, Slammerワームに対して、アンチワームを生成する実験を行った。

ワームを除去するためのワームを作ってばらまこうって研究は遅くとも2000年付近からはあった気がする。ワームコードを解析・変換してアンチワームを自動生成するって点が新規?

タイトルにもある通り研究はまだ予備的段階という感じ。ていうか目標がかなり野心的なので、汎用的に使える技術が編み出せるのかどうか自体がまだわからない。

| ホーム |


 BLOG TOP 


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。