プロフィール

大山恵弘

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

最近の記事

最近のコメント

最近のトラックバック

月別アーカイブ

ブロとも申請フォーム

ブログ内検索

RSSフィード

リンク

FC2カウンター

スポンサーサイト

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

【セキュリティ】 Defending Embedded Systems Against Buffer Overflow via Hardware/Software 【特殊ハードウェア】

In ACSAC '03.
http://www.acsa-admin.org/2003/abstracts/76.html

バッファオーバフローを防ぐためのハードウェア拡張(とそれを利用した防御機構)の提案。2つからなる。

1つめ。スタックスマッシュ対策。
プロセッサのパイプラインの書き込みフェーズの前に、アドレスチェックフェーズをはさむ。アドレスチェックフェーズで、書き込み対象アドレスの値がフレームポインタの値と同じまたはそれより大きいと判定されたら、書き込みが失敗する。

2つめ。関数ポインタ改変対策。
各プロセスにランダムなキーを割り当て、それを特殊レジスタRに格納する。新しいジャンプ命令SJMPを導入する。SJMPは、受け取ったアドレスをRとXORして、その結果のアドレスに飛ぶ。

ARMエミュレータ上で評価。
スポンサーサイト

【セキュリティ】 Install-time vaccination of Windows executables to defend against stack smashing attacks 【バッファオーバフロー】

In 9th IFIP International Information Security Conference, 2004.
http://www.eng.tau.ac.il/~yash/sum-pubs.html

WindowsにStackGuard風の戻りアドレス破壊検出を入れたって研究。

ポイントを以下にまとめる。

  • Windowsに適用した。
  • カナリア方式ではなく特殊スタック導入方式。
  • メモリイメージ書き換えでもなく、コンパイラ改造でもなく、実行可能バイナリファイルを書き換えるアプローチ。関数先頭の数命令を、instrumentationコードのへのジャンプ命令に書き換える。
  • 逆アセンブルにはIDA Proを利用。
  • SPEC2000の性能低下は8%以下。コードサイズ増加は20%から37%。

ここから下が、特に重要に思われる新規性。

  • DLLを扱える。
  • マルチスレッドを扱える。
  • マルチスレッドアプリから呼び出されたDLLも扱える。
  • Detoursより広範囲の関数をinstrumentできる(すごく小さい関数とか)
  • 実際の攻撃コードで実験した。

StackGuardみたいな仕組みをWindowsでも使おうってのは自然な考えで、よく理解できる。

本研究の手法は、C言語のメモリ安全性の欠如を利用する攻撃すべてを防げるわけではない。なので、乗っ取りが成功してしまった後でも何とか安全性を保つための方法も組み合わせて使うことが重要に思われる。たとえば、プログラムの動作を監視して、動作が怪しいとか怪しくないとかの判断に基づく侵入検知を行うなど。

【セキュリティ】 Neutralizing Windows-Based Malicious Mobile Code 【OS】

In ACM SAC 2002.

Windows上で悪意コードを監視するシステムIMPを構築した。IMPはすべてのプロセス生成を監視し、名前が監視対象に含まれるプロセス(OUTLOOK.EXEとかIEXPLORE.EXEとか)の監視を行う。

研究内容を読み取りやすい論文ではないと思うが、がんばって読み取ってみる。

IMPはソケットAPIの使用を検知でき、それを通じた感染を防ぐ?

IMPはアプリケーションによるレジストリ変更をフックし、防ぐことができる?

IMPはシステムディレクトリのファイルへの書き込みを防ぐことができる?

たぶん、システムコールフック機能もある。ただし、彼らがシステムコールと呼んでいるものは、おそらくユーザレベルのライブラリ関数のコール。

述べられているフック方式は、
(1) ディスク上の実行可能バイナリの書き換え(mykernel32.dllを作るなど)
(2) メモリ上のdispatchテーブルの書き換え
(3) Callee側の関数内容の書き換え(Detours方式?)
の3つ。IMPがどれを採用しているかは、たぶん、書かれていない。

監視には、マニュアルモードと自動モードがある。マニュアルモードでは、怪しい動作が試みられたら、ユーザに、その動作の実行を許可するかどうか聞く。自動モードでは、ファイルおよびレジストリへの更新をログに記録し、それらのバックアップを作成して、そのまま実行する。もし後でそのアプリケーションが悪意のあるものだとわかったら、そのログやバックアップを利用してファイルを安全なものに戻す。

ILOVEYOUウィルスの動作を止める実験を行っている。

UNIXではよくあるタイプの研究だと思うが、Windowsでやったあたりが一つの貢献か。

思うところが2つある。

一つは、ユーザレベルでシステムコールをフックしているので、悪意コードに簡単にバイパスされてしまう可能性があるということ。バイパスされないためには、System Serviceのフックに切り替えるなどの対策が必要に思われる。

もう一つは、ファイルとレジストリを単純にundoして良いのかということ。コンシステンシが崩れてクラッシュするアプリケーションが出てくるような気がする。

【セキュリティ】 Thirty Years Later: Lessons from the Multics Security Evaluation 【OS】

In ACSAC 2002.
http://www.acsa-admin.org/2002/abstracts/classic.html

Classic papersセッションの論文。

1974年に行われた、当時のセキュアなシステムの脆弱性解析(特にMulticsに関する解析)を振り返り、現在のセキュリティ状況に照らして考察を行う。

読み飛ばしても問題なさそうな部分(あまり技術的でない昔話など)が多い論文と思うが、一ヶ所、大変に興味深い部分があった。
Multicsはバッファオーバフローにほとんど悩まされていない。その理由は?

という部分。

答えは論文のSection 2.3 No Buffer Overflowsに。

【仮想マシン】 HARPY: A Virtual Machine Based Approach to High-Throughput Cluster Computing 【高性能計算】

Technischer Bericht
http://cluster.inf-ra.uni-jena.de/harpy/

サーバ上でLinuxVMを動かして高性能計算する。
それらのVMは遊休Windows PCにマイグレーションして実行される。
マイグレーションは透明である(アプリケーションはマイグレーションに気がつかない)。

VMにはcoLinuxを利用。
ネットワークの仮想化にはTAPドライバを利用。
マイグレーションには、シングルシステムイメージミドルウェアOpenMOSIXを利用。

Condorっぽくもあり、SETI@homeっぽくもあり、capsuleっぽくもある。

この手の研究だと、VMwareかUMLかXenを採用するのがポピュラーだと思うが、coLinuxを採用した点にこだわりを感じる。VM上でサーバ運用じゃなくて高性能計算やるってのもしぶい。

シングルシステムイメージの概念をVMに導入した研究としては、こんなのがあります。

VMのマイグレーションの研究としては、こんなのとか。

【フック】 Detours: Binary Interception of Win32 Functions 【Windows】

In 3rd USENIX Windows NT Symposium.
http://research.microsoft.com/sn/detours/

Win32の関数にinterception codeを入れるためのライブラリ。
ユーザはアプリケーションコードの中でdetoursライブラリ関数を呼ぶ。その関数の引数には、interceptされるWin32の関数名と、interception codeを提供する関数名を与える。その関数は、メモリ上に存在する、interceptされる関数の先頭の命令列を、interception codeを提供する関数へのジャンプ命令列に書き換える。

Windows上で関数をinterceptする方式について述べている数少ない論文の一つ。

ついついセキュリティへの応用を考えたくなるが、Detoursはセキュリティ用途には使いにくいように思う。資源を操作する重要な関数の呼び出しに検査を挟んで、資源を不正に操作されないようにするなんて処理は、Detoursではうまく実現できない。たとえば、バッファオーバフローによって注入されたコードは、直接System Serviceを呼び出すことによって、悪意の操作を実行できる。注入コードをここに述べられてるような凝ったものにすれば、注入コードはinterceptionをバイパスしてオリジナルの関数に直接飛ぶことができる。

セキュリティ用途に使うなら、System Serviceの直接呼び出し対策やバイパス対策が必須。
もしくは、Detours方式は捨てて、System Serviceフック方式を採用してしまうのが、筋が良いように思われる。

【ディペンダブル】 On the Challenge of Delivering High-Performance, Dependable, Model-Checked Internet Servers 【モデル検査】

In HotDep'05.
http://hotdep.org/2005/

ディペンダブルなサーバの構築に向けての取り組み。

題材はSSH v2。安全なSSH v2サーバを作る。

OCamlで実装してバッファオーバフローを排除する。
サーバがポリシーに従うことを静的にモデル検査で保証または動的検査で強制する。サーバの動きをオートマトンで表現して、それを検査。ポリシー記述には、C-likeな文法で非決定性有限オートマトンを表現するドメイン特化言語を利用。

ちょっと読んだ感じではSekarらのMCCに近い感じ。

SSHではなくメールサーバ・クライアントですけど、このへんも似た仕事をしてるかも。

【モデル検査】 Automatic Discovery of API-Level Exploits 【セキュリティ】

In ICSE 2005.
http://www.cs.wisc.edu/wisa/papers/icse05/index.html

呼び出してるAPIの低レベルな詳細を抽象化で失わせないようにしつつ、アプリケーションをモデル検査して、脆弱性とexploitを発見する枠組みの提案。
Bounded, infinite-state model checking。
printfのフォーマット文字列APIとIBMの暗号鍵管理APIをこの枠組みでモデル化した。両者に対してexploitを発見することができた。php, qpopper, wu-ftpで、(既知の脆弱性に対する)exploitを発見できた。

泥くさい世界の泥くさい問題をきれいな道具で解決します系の研究。論文も泥
くさいようなきれいなような。提案の枠組みを適用した2つの対象はややマイ
ナーというか、少し微妙だが、今後、よりメジャーな対象にも適用されると
おもしろいなと思います。

モデル検査のちょっと変わった対象への応用としては、こんなのがあります。

【異常検知】 Detecting Malicious Software by Monitoring Anomalous Windows Registry Accesses 【Windows】

In RAID 2002.
http://www1.cs.columbia.edu/ids/publications.html

Windowsのレジストリアクセス挙動を学習。その学習データをもとに異常検知する。部分イベント列の集合やイベントオートマトンで挙動を特徴化するのではなく、各イベントがどの程度の確率で発生するかの情報にもとづいて異常かどうかを判断。同じ年に発表されたテキスト分類ベース異常検知に方向が近い?

レジストリアクセスはWin32をフックしてつかまえる。

UNIXのシステムコールで学習ベースの異常検知するって研究は10年以上の歴史があり、論文も山のようにある。でもWindowsでそれをやった研究は非常に少ない。UNIXで培われてきた技法がWindows(をはじめとする非UNIX系OS)でも意味があるのかどうかはopen questionであり、非常に興味深い。この研究は、レジストリが異常検知の手がかりとしてある程度有用であることを示している。

このへんとかこのへんにも、学習に基づく異常検知の研究があります。

| ホーム |


 BLOG TOP 


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