ソースコードを元にソフトウェアの異常な動作を検知する侵入検知システム 21
OSS専用の侵入検知システム 部門より
あるAnonymous Coward 曰く、
そのソースコードを元に、ソフトウェアの異常な振る舞いを検知するシステムが開発されている。このシステムは「Korset」と呼ばれており、開発者はテルアビブ大学のAvishai Wool教授と院生のOhad Ben氏だ（Science Daily・本家/.）。
Korsetはホストベースの侵入検知システム（Host-based Intrusion Detection Systems、HIDS）の1種で、動作するアプリケーションを監視し、もしアプリケーションが攻撃され、バッファオーバフローなどによって想定外の動作を行おうとした際にそれをブロックする、というものだ。
一般的にこのようなシステムでは、あらかじめアプリケーションごとに許可する動作/許可しない動作を手動で指定したり、アプリケーションを動作させて許可する動作を学習させておく必要があった。いっぽうKorsetでは、アプリケーションのソースコードからアプリケーションの振る舞いを認識し、ソースコードに記述されていない動作を行おうとした際に、その動作をブロックする。
（つづく...）
詳しくはオタワLinuxシンポジウムで発表された論文を確認してほしいが、動作原理としてはソースコードからそのアプリケーションが呼び出すシステムコールの呼び出し順とその遷移のパターンを抽出し、そのパターンとは異なる順番でシステムコールが発行された場合、想定していない動作と見なしてブロックする、というもののようだ。
ただし、Korsetではそのソースコードが完全に入手できるアプリケーションしか対応できないほか、マルチスレッドやsetjmp、longjmpなどを利用するアプリケーションには対応していない、といった課題も残されている。また、システムコールをトラップするため、利用にはカーネルの修正が必要であるとのことだ。
これを使えば (スコア:4, おもしろおかしい)
Re:これを使えば (スコア:2, すばらしい洞察)
Re:これを使えば (スコア:1)
書いてあるとおりの挙動だったりします。
# 思ったとおり、ではなくて。
-- Tig3r on the hedge
すると攻撃方法は… (スコア:4, すばらしい洞察)
『どのような順番でシステムコールを発行するべきか』
に従ってシステムコールを発すれば良い、と。
ほぼ全てのソフトが open/close/mmap/read/write を必ず実行する以上、守れる範囲はそんなに広くない気もするが…???
実際問題として、攻撃対象になるようなソフトって大抵 fork/exec もするだろうし…
fjの教祖様
Re: (スコア:0)
ここらへんからふと思いついたんだけど、Xenに組み込んだりできないのかな？
予めソースを手に入れて、そのソースを元にモジュールを作って組み込み、という感じからしてSELinuxのような感じになるのかな？
# いや。仕事前の感想にて、失礼
Re:すると攻撃方法は… (スコア:2, 興味深い)
あぁ、でもそれは Linux では駄目だ。実装できない。
Linus君、micro kernel が大嫌いだったからな
fjの教祖様
Re:すると攻撃方法は… (スコア:1)
Re:すると攻撃方法は… (スコア:1)
fjの教祖様
Re:すると攻撃方法は… (スコア:1)
移植性を保つには「だいたいの環境で使える」って機能に依存するわけにはいかんだろ。
Re:すると攻撃方法は… (スコア:1)
「どこで何をするのかなど全部事前に判っているのだから、そんな機能はいらん。
それよりも1個あたりの値段を10円安くしろ」
という声は私自身、直接聞いたこともあります。組み込みの場合、Supervisor mode, MMU, FPUは『いらないから消せ』といわれる3大機能ですな。
つまり、2モードって意外と珍しいって事です。1か、あるいは3以上、はたくさんある。
fjの教祖様
Re:すると攻撃方法は… (スコア:1)
68k系だってSHだってMIPS(R3000以前を故意に無視してない？)だってARMだって大抵2モードじゃないか？何にしてもLinuxは現状では2モードしか使ってないし2モードのプロセッサ用ツリーがある以上、3モード以上を使うようになるとは思えんよ。RING1/2を使うように改造することはできるだろうけど、前にも書いたようにそれをするだけのメリットがあるようには思えないし。
ところで、2つ以上のモードを使うことがセキュリティ的にメリットがあってメジャーなプロセッサでは2モード以上使えるのなら、OpenBSDあたりは当然2モード以上使ってるはずだと思うんだけど、これについてはどう思う？「個人的には実行時に怪しい動作を検出する」などというのは下策であって「そもそも悪さをする方法自体をなくすように設計する」というのが正しいアプローチだと思うけどね。
Re:すると攻撃方法は… (スコア:1)
どう思うではなく、根本的に「使うわけ無いじゃん」が答。
モノリシックカーネルデザイン上でセキュリティを構築するなら、2モードだろうね。kernelモード内に存在するものは全て信頼できる、と言うのがモノリシックカーネルの大前提だから。
OpenBSDは「kernel 自身は信じている」という大前提で作られている。kernelが提供する機能を信頼せず、userland に追い出そうとはしておらず、その代わり kernel内部のコードの信頼性を高めるためにレビューを繰り返している。だから、OpenBSDでマルチモードが採択されることは(OpenBSD自身が micro kernel デザインにならない限り)ありえない。
.
マルチモードデザインは、基本的に Mach のように
1) まず全てのリソースを操作できる micro kernel がいて、
2) デバイスドライバーや system call emulator のように micro kernel 上でユーザーのためのサービスを提供するための一連の supervisor process が存在して(つまり、ユーザー空間を必要に応じてアクセスできる特権者としてのプロセスがいて)
3) supervisor process の提供するサービスを利用する user process がいる
時に初めて役に立つ。2のレベルと3のレベルが「別物でなくてはいけない」かつ2のレベルは3のレベルを自由に制御できなくてはいけない(1まで戻らないと制御できないのでは、2で提供できるはずの機能を1に盛り込まなくてはいけないから)というスタンスに立った場合に初めて意味が出てくる。
現実問題として、このような制御方式はマルチプロセッサ(マルチコアでもいいが)が当たり前にならないと全然性能が出ない。だから、今までは無かった。それだけの話。
fjの教祖様
検知システム内会議 (スコア:2, おもしろおかしい)
Ｂ「私はこういう動作のプログラムを他にも知っています。別に珍しくもありませんよ。」
Ａ「お前の周りが変なんだよ！まともなプログラムとも付き合えよｗ」
Ｂ「それでは何をもって異常を定義するのですか？」
Ａ「常識で考えろよ……まったくナードは厄介だ」
Ｂ「そうやってレッテルを貼って逃げるのですね？」
Ａ「じゃあこのプログラムの動作が攻撃によるものでないと証明できるのか？」
Ｂ「悪魔の証明ですね。詭弁ですね。」
Ｃ「あれ？どこかで無限ループが発生してない？」
Re: (スコア:0)
Ａ「この動作は異常だろ……ソースに、こんな呼び出し書かれてないぜ」
Ｂ「なるほど、攻撃者に送り込まれたコードが動いてるんだ」
というものだと。
Re: (スコア:0)
ちゃんと検知ロジックまで組み込まれているとは
# D「いや、もう少しみてみようぜ」
# E 「そうだな」
自己言及 (スコア:1)
カーネルを修正したことによって起こりうる異常な動作は検知できますか？
その？ (スコア:0)
Re: (スコア:0)
これのことけ？
あるソフトウェアがあって、そのソースコードを元に、そのソフトウェアの異常な振る舞いを～、だね。
文学的表現だなww
仕様バグは検知できませんな (スコア:0)
ソースコードに書いてあることだし。
Re: (スコア:0)
例えば、コーディングのミスが原因でバッファオーバフローを引き起こす可能性ががある場合、
実際にそこを突かれて任意のコードを実行されて"有り得ない"システムコールのシーケンスが
発生した時点で初めて検出されるわけで。
ソースコードや仕様レベルで問題部分を指摘するなんてのは、最初から狙ってないかと。
静的解析には期待するけど (スコア:0)
動的生成されるコードまで面倒を見るには、静的解析によって「あるコード生成コードが生成可能な全てのコード」に対する性質が証明できれば良いわけだけれど、そのためにはコード生成をするコードを高レベルで記述できる言語が必要になりそうだ。