セキュリティテスト-Buffer overrun
セキュリティテスト-Buffer overrun
BOって何?
BOの概念は分かりやすく、C言語の基本知識だけで十分です.メモリを申請しましたが、入力されたデータはこのメモリより大きく、入力されたデータはこのメモリ以外のメモリを上書きしました.たとえば、
void foo( char * input) { char buf[100]; strcpy (buf, input); }
長さチェックは行われず、ハッカーがinputを操作すると、戻りアドレスが書き換えられ、セキュリティの問題が発生する可能性があります.
なぜBOは安全問題なの?
copyのデータがstackで宣言されたbufferより大きい場合、bufferはoverwrittenされ、stackベースのbuffer overrunが生成される.stackで宣言された変数は関数呼び出し者の戻りアドレスにあり,戻りアドレスは攻撃者に書き換えられ,BOで悪意のあるコードを実行してコンピュータを制御する.
X86 EBP Stack Frame
Highest address Arguments
Return address
Previous EBP
Saved rigisters
local storage
Lowest address
C言語では、関数を呼び出すとき、アセンブリまたはマシンコードのレベルはどのように実現されますか?上の関数fooを呼び出すと、プログラムのstackが下のグラフのようになります.まず、入力パラメータはスタックに配置され、その後、この関数が実行された次の命令のアドレス、すなわちreturn address、次いでEBP、そしてこの関数のローカル変数のメモリ空間になります.例えばこの関数は100バイトの空間を申請した.BOが発生すると、データはbuf後のメモリを上書きし、肝心な部分はreturn addressが上書きできることです.ハッカーはreturn addressの値をこのbufのアドレス、例えば開始アドレスbuf[0]のアドレスに変更することができ、このbufにはハッカー自身のコードが埋め込まれている.これにより、この関数が終了すると、プログラムはreturn addressで指定されたコード、すなわちハッカーのコードを実行します.
セキュリティテスト
最高レベルでは、セキュリティ・ホールの発掘方法は、ホワイト・ボックス、ブラック・ボックス、グレー・ボックスのテスト方法の3つに分類されます.テスト者が得ることができるリソースは,この3つの方法の違いを決定する.ホワイトボックステストでは、ソースコードを含む使用可能なすべてのリソースを使用する必要がありますが、ブラックボックステストでは、ソフトウェアの入力と観察された出力結果のみにアクセスします.両者の間にあるのはグレーボックステストであり、ブラックボックステストに基づいて使用可能なバイナリファイルの逆工程によって追加の分析情報を得た.
ホワイトボックステストには、さまざまなソースコード分析方法が含まれています.コンパイル時インスペクタ、ソース・ブラウザ、または自動ソース・コード監査ツールなど、自動化ツールを使用して手動で完了することもできます.
グレーボックステスト定義は、まずブラックボックステストレビューを含み、また、逆方向エンジニアリング(RE)によって得られた結果も含まれ、逆方向エンジニアリングは逆方向コードエンジニアリング(RCE)とも呼ばれる.解析コンパイル後に得られたアセンブリ命令は,類似の物語を解明するのに役立つが,より多くの努力が必要である.ソース・コード階層ではなくアセンブリ・コード階層でセキュリティ評価を行うセキュリティ評価は、典型的にはバイナリ・レビュー(binary auditing)と呼ばれる.バイナリレビューは、「内側から外側へ」というテクノロジーとも呼ばれます.研究者は、まず、逆アセンブリ結果に興味を持つ可能性のある脆弱性を認識し、ソースコードに逆方向に遡って、脆弱性が他の人に利用されるかどうかを決定します.
デバッガは、アプリケーションが実行中のCPUレジスタの内容とメモリの状態を表示できます.Win 32プラットフォームの下で流行しているデバッガは、実行時のスクリーンショットであるOllyDbg 18を含む.他にもMicrosoft WinDbg(wind bagとも呼ばれる)19もあります.WinDbgは、Windowsソフトウェアデバッグキット20の一部であり、Microsoftのウェブサイトから無料でダウンロードできる.OllyDbgはOleh Yuschukによって開発されたデバッガで、ユーザーフレンドリー性はWinDbgよりやや優れています.両方のデバッガでは、ユーザがカスタム拡張機能コンポーネントを作成することができ、多くのサードパーティ製プラグインがOllyDbgの機能21を拡張するために使用できる.UNIX環境下でも様々なデバッガがあり、GNU Project Debugger 22(GDB)が最もポピュラーで移植されやすいデバッガです.GDBはコマンドラインデバッガで、多くのUNIX/Linux製品にこのデバッガが含まれています.
ブラックボックステストを実行する場合、ソースコードは使用できません.ブラックボックステストで実行します.ファジイ試験と組み合わせて行うことが考えられる.
Fuzz Test
Fuzz Testコンセプト
従来のFuzzは、ソフトウェアの欠陥(flaws)を発見するためのブラックボックス試験技術またはランダム試験技術を指す.ファジイテストは、製品に無効なデータを意識的に入力して、エラー条件をトリガーしたり、製品の障害を引き起こしたりすることを期待するプロセスです.これらのエラー条件は、掘り起こし可能なセキュリティ・ホールの特定を指導することができる.
1990年にMillerらは、簡単なFuzz testingによってUNIXシステム上で実行される少なくとも25%のプログラムをクラッシュさせることができることを発見した.2002年にAitelが独自の設計で実現したFuzzツールSPIKEは、複数の未知の脆弱性を発見することに成功した.セキュリティ・ホールは、MicrosoftのInternet Explorer、Word、Excelなど、多くのポピュラーなクライアント・アプリケーションを悩ませています.これらの脆弱性の多くは、2006年にファジイテスト・テクノロジーによって発見されました.ファジイ試験技術の有効な応用は多くの新しいツールと日増しに広範な影響をもたらした.安全分野におけるFuzzテストの重要性が明らかになった.
セキュリティはソフトウェア開発ライフサイクル(SDLC)に組み込まれなければならず、最後になってから軽率に処理されるわけではありません.ファジイ試験は任意の完全なSDLCの一部であり、試験段階だけでなく、開発段階も同様に考慮する必要がある.欠陥が発見されれば発見されるほど、欠陥を補修するコストは低くなる.
Fuzz技術の原理
Fuzz技術の原理は簡単で、基本的な思想はランダムなデータをプログラムの入力として、そしてプログラムの実行中に発生したいかなる異常を監視して、異常を招いた人に送るデータを記録して、それによってソフトウェアの中で欠陥の位置を位置決めします.
Fuzzフェーズ
ファジイ試験法の選択は異なる要因に依存し,大きな変化がある可能性がある.絶対的に正しいファジイ試験方法はありません.ファジイ試験方法の選択は、ターゲットアプリケーション、研究者のスキル、および試験が必要なデータのフォーマットに完全に依存します.しかしながら、ファジイ試験は、何を試験しても、どの方法を選択したかを決定しても、いくつかの基本的な段階を経なければならない.
ここで、識別入力:ほとんどの利用可能な脆弱性は、アプリケーションがユーザの入力を受け入れ、入力データを処理する際に不正なデータを最初に消去したり、確認ルーチンを実行したりしていないためである.
経験紹介
APIテスト:
Memory Boundary Test for GetPluginVersion:
Buffer is bigger than needed Buffer;
content is setted to be 0xFF before calling the fuction
Input buffer with sizeWChar is bigger than the actual value
Expected Results:The lower bytes of the buffer is the actual vertion information,and other bytes is the setted 0xFF before calling the fuction.
ソースコードを読むと、Strcpy、memcopyなどの関数呼び出しを表示する前に、このようなBugを検索することもできます.また、CreateProcess()を安全に呼び出さないと、脆弱性が発生します.
Prefast、Fxcopなどのツールでテストします.
APテスト:
ブラックボックステスト:
たとえば、Nameドメインは文字列値を受け入れるべきであり、Ageドメインは整数値を受け入れるべきであると仮定します.もしユーザーが偶然2つのドメインの実際の入力範囲を変更し、Ageドメインに文字列を入力した場合、何が起こるのでしょうか.文字列の値は自動的にASCIIコードに基づく整数値に変換されますか?エラーレポートメッセージが表示されますか?アプリケーションがクラッシュしますか?ファジイ自動化テストにより実現する.
ツールまたはソースコードチェックで行うこともできます.
Arguments
Return address
Previous EBP
Saved rigisters
local storage最高レベルでは、セキュリティ・ホールの発掘方法は、ホワイト・ボックス、ブラック・ボックス、グレー・ボックスのテスト方法の3つに分類されます.テスト者が得ることができるリソースは,この3つの方法の違いを決定する.ホワイトボックステストでは、ソースコードを含む使用可能なすべてのリソースを使用する必要がありますが、ブラックボックステストでは、ソフトウェアの入力と観察された出力結果のみにアクセスします.両者の間にあるのはグレーボックステストであり、ブラックボックステストに基づいて使用可能なバイナリファイルの逆工程によって追加の分析情報を得た.
ホワイトボックステストには、さまざまなソースコード分析方法が含まれています.コンパイル時インスペクタ、ソース・ブラウザ、または自動ソース・コード監査ツールなど、自動化ツールを使用して手動で完了することもできます.
グレーボックステスト定義は、まずブラックボックステストレビューを含み、また、逆方向エンジニアリング(RE)によって得られた結果も含まれ、逆方向エンジニアリングは逆方向コードエンジニアリング(RCE)とも呼ばれる.解析コンパイル後に得られたアセンブリ命令は,類似の物語を解明するのに役立つが,より多くの努力が必要である.ソース・コード階層ではなくアセンブリ・コード階層でセキュリティ評価を行うセキュリティ評価は、典型的にはバイナリ・レビュー(binary auditing)と呼ばれる.バイナリレビューは、「内側から外側へ」というテクノロジーとも呼ばれます.研究者は、まず、逆アセンブリ結果に興味を持つ可能性のある脆弱性を認識し、ソースコードに逆方向に遡って、脆弱性が他の人に利用されるかどうかを決定します.
デバッガは、アプリケーションが実行中のCPUレジスタの内容とメモリの状態を表示できます.Win 32プラットフォームの下で流行しているデバッガは、実行時のスクリーンショットであるOllyDbg 18を含む.他にもMicrosoft WinDbg(wind bagとも呼ばれる)19もあります.WinDbgは、Windowsソフトウェアデバッグキット20の一部であり、Microsoftのウェブサイトから無料でダウンロードできる.OllyDbgはOleh Yuschukによって開発されたデバッガで、ユーザーフレンドリー性はWinDbgよりやや優れています.両方のデバッガでは、ユーザがカスタム拡張機能コンポーネントを作成することができ、多くのサードパーティ製プラグインがOllyDbgの機能21を拡張するために使用できる.UNIX環境下でも様々なデバッガがあり、GNU Project Debugger 22(GDB)が最もポピュラーで移植されやすいデバッガです.GDBはコマンドラインデバッガで、多くのUNIX/Linux製品にこのデバッガが含まれています.
ブラックボックステストを実行する場合、ソースコードは使用できません.ブラックボックステストで実行します.ファジイ試験と組み合わせて行うことが考えられる.
Fuzz Test
Fuzz Testコンセプト
従来のFuzzは、ソフトウェアの欠陥(flaws)を発見するためのブラックボックス試験技術またはランダム試験技術を指す.ファジイテストは、製品に無効なデータを意識的に入力して、エラー条件をトリガーしたり、製品の障害を引き起こしたりすることを期待するプロセスです.これらのエラー条件は、掘り起こし可能なセキュリティ・ホールの特定を指導することができる.
1990年にMillerらは、簡単なFuzz testingによってUNIXシステム上で実行される少なくとも25%のプログラムをクラッシュさせることができることを発見した.2002年にAitelが独自の設計で実現したFuzzツールSPIKEは、複数の未知の脆弱性を発見することに成功した.セキュリティ・ホールは、MicrosoftのInternet Explorer、Word、Excelなど、多くのポピュラーなクライアント・アプリケーションを悩ませています.これらの脆弱性の多くは、2006年にファジイテスト・テクノロジーによって発見されました.ファジイ試験技術の有効な応用は多くの新しいツールと日増しに広範な影響をもたらした.安全分野におけるFuzzテストの重要性が明らかになった.
セキュリティはソフトウェア開発ライフサイクル(SDLC)に組み込まれなければならず、最後になってから軽率に処理されるわけではありません.ファジイ試験は任意の完全なSDLCの一部であり、試験段階だけでなく、開発段階も同様に考慮する必要がある.欠陥が発見されれば発見されるほど、欠陥を補修するコストは低くなる.
Fuzz技術の原理
Fuzz技術の原理は簡単で、基本的な思想はランダムなデータをプログラムの入力として、そしてプログラムの実行中に発生したいかなる異常を監視して、異常を招いた人に送るデータを記録して、それによってソフトウェアの中で欠陥の位置を位置決めします.
Fuzzフェーズ
ファジイ試験法の選択は異なる要因に依存し,大きな変化がある可能性がある.絶対的に正しいファジイ試験方法はありません.ファジイ試験方法の選択は、ターゲットアプリケーション、研究者のスキル、および試験が必要なデータのフォーマットに完全に依存します.しかしながら、ファジイ試験は、何を試験しても、どの方法を選択したかを決定しても、いくつかの基本的な段階を経なければならない.
ここで、識別入力:ほとんどの利用可能な脆弱性は、アプリケーションがユーザの入力を受け入れ、入力データを処理する際に不正なデータを最初に消去したり、確認ルーチンを実行したりしていないためである.
経験紹介
APIテスト:
Memory Boundary Test for GetPluginVersion:
Buffer is bigger than needed Buffer;
content is setted to be 0xFF before calling the fuction
Input buffer with sizeWChar is bigger than the actual value
Expected Results:The lower bytes of the buffer is the actual vertion information,and other bytes is the setted 0xFF before calling the fuction.
ソースコードを読むと、Strcpy、memcopyなどの関数呼び出しを表示する前に、このようなBugを検索することもできます.また、CreateProcess()を安全に呼び出さないと、脆弱性が発生します.
Prefast、Fxcopなどのツールでテストします.
APテスト:
ブラックボックステスト:
たとえば、Nameドメインは文字列値を受け入れるべきであり、Ageドメインは整数値を受け入れるべきであると仮定します.もしユーザーが偶然2つのドメインの実際の入力範囲を変更し、Ageドメインに文字列を入力した場合、何が起こるのでしょうか.文字列の値は自動的にASCIIコードに基づく整数値に変換されますか?エラーレポートメッセージが表示されますか?アプリケーションがクラッシュしますか?ファジイ自動化テストにより実現する.
ツールまたはソースコードチェックで行うこともできます.
APIテスト:
Memory Boundary Test for GetPluginVersion:
Buffer is bigger than needed Buffer;
content is setted to be 0xFF before calling the fuction
Input buffer with sizeWChar is bigger than the actual value
Expected Results:The lower bytes of the buffer is the actual vertion information,and other bytes is the setted 0xFF before calling the fuction.
ソースコードを読むと、Strcpy、memcopyなどの関数呼び出しを表示する前に、このようなBugを検索することもできます.また、CreateProcess()を安全に呼び出さないと、脆弱性が発生します.
Prefast、Fxcopなどのツールでテストします.
APテスト:
ブラックボックステスト:
たとえば、Nameドメインは文字列値を受け入れるべきであり、Ageドメインは整数値を受け入れるべきであると仮定します.もしユーザーが偶然2つのドメインの実際の入力範囲を変更し、Ageドメインに文字列を入力した場合、何が起こるのでしょうか.文字列の値は自動的にASCIIコードに基づく整数値に変換されますか?エラーレポートメッセージが表示されますか?アプリケーションがクラッシュしますか?ファジイ自動化テストにより実現する.
ツールまたはソースコードチェックで行うこともできます.