JP3552627B2 - スタック保護システム、コンピュータシステム、コンパイラ、スタック保護方法および記憶媒体 - Google Patents
スタック保護システム、コンピュータシステム、コンパイラ、スタック保護方法および記憶媒体 Download PDFInfo
- Publication number
- JP3552627B2 JP3552627B2 JP2000028358A JP2000028358A JP3552627B2 JP 3552627 B2 JP3552627 B2 JP 3552627B2 JP 2000028358 A JP2000028358 A JP 2000028358A JP 2000028358 A JP2000028358 A JP 2000028358A JP 3552627 B2 JP3552627 B2 JP 3552627B2
- Authority
- JP
- Japan
- Prior art keywords
- stack
- program
- variable
- function
- guard
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4482—Procedural
- G06F9/4484—Executing subprograms
- G06F9/4486—Formation of subprogram jump address
Description
【０００１】
【発明の属する技術分野】
本発明は、スタックスマッシング攻撃によるコンピュータへの侵入からプログラムカウンタを保護するスタック保護方法に関する。
【０００２】
【従来の技術】
コンピュータシステムヘの侵入は、一般に、システム設定の不備やセキュリティホールと呼ばれるシステムの弱点を攻撃して他人の権限で侵入し、次の攻撃でシステム管理者権限を得るといった手順で行われる。
【０００３】
このような攻撃の典型的なものとしてスタックスマッシング攻撃がある。スタックには、プログラム内のサブルーチンの実行状態を保持するために、サブルーチンのリターンアドレス、ローカル変数、引数などが保管される。そして、スタックスマッシング攻撃は、スタック内のリターンアドレスを書き換えることによって悪意のあるプログラムに実行制御を移すという手法である。
【０００４】
スタックの構造を示してスタックスマッシング攻撃について具体的に説明する。図９はＣ言語における関数呼び出し後のスタック状態を示している。図９を参照すると、スタックトップ（図では下側）から順に、ローカル変数（Ｌｏｃａｌ Ｖａｒｉａｂｌｅ：ＬＶ）、当該関数の呼び出し元である直前の関数のフレームポインタ（Ｐｒｅｖｉｏｕｓ ｆｒａｍｅ ｐｏｉｎｔｅｒ：ＰＦＰ）、及び当該呼び出し元へのリターンアドレス（Ｒｅｔｕｒｎ Ａｄｄｒｅｓｓ：ＲＡ）が積まれている。ここで、フレームポインタ（ｆｒａｍｅ ｐｏｉｎｔｅｒ：ＦＰ）とは、ローカル変数が相対参照される際のベースポインタの事である。スタックスマッシング攻撃においては、ローカル変数（特に配列）への代入操作を行い、境界チェックが不完全な場合に、そのローカル変数より上位のスタック領域を破壊する。そして、スタック領域を破壊する際に、プログラムを書き込むと共に、リターンアドレスの領域にそのプログラムを指すような値を書き込む。この状態で関数のリターン処理が行われると、書き込まれたプログラムが起動することとなる。
【０００５】
Ｃ言語で記述されたプログラムを例にして、スタックスマッシング攻撃について、さらに具体的に説明する。図１０はスタックスマッシング攻撃の攻撃対象であるＣ言語で記述されたプログラムの例であり、図１１はこのプログラムに対してスタックスマッシング攻撃が行われた場合のスタックの状態を説明する図である。図１０において、関数ｆｏｏは環境変数ＨＯＭＥの内容をローカル変数にコピーするプログラムである。関数ｓｔｒｃｐｙはローカル変数の大きさを考慮しないため、環境変数ＨＯＭＥの内容が１２８文字以上である場合、図１１のｂｕｆから上方向の内容（網掛け箇所）を壊すことになる。この破壊内容にプログラムを埋め込み、かつリターンアドレスの領域にそのプログラムの先頭アドレスを置くことによって、埋め込んだプログラムへ制御を移すことができる。
【０００６】
上述したスタックスマッシング攻撃などにより、他人の管理するコンピュータネットワークに侵入する行為は、それ自体が機密漏洩やシステム破壊などを引き起こす場合がある。また、他人のＩＤやパスワードを盗み、その正当な所有者のふりをしてシステムに侵入するなりすまし行為や、他のコンピュータに侵入するための足がかりとして利用される場合もある。
従来、この種のスタックスマッシング攻撃は、ＵＮＩＸサーバを主な攻撃目標としていた。しかし最近では、ＡｃｔｉｖｅＸ（Ａｃｒｏｂａｔ Ｃｏｎｔｒｏｌ ｆｏｒ ＡｃｔｉｖｅＸなど（なお、ＡｃｔｉｖｅＸは米国マイクロソフト・コーポレーションの商標）のバッファオーバーフローが問題となり、これを対象とする攻撃が行われるようになっている。そのため、ネットワークに接続するコンピュータ一般、すなわち、サーバマシン、クライアントマシン、ＰＤＡなどの全てが攻撃目標となり得る。
バッファオーバーフローを起こすバグは、発見されてから取り除かれるというのが一般的である。したがって、このバグに対する攻撃を防ぐには、そのような攻撃に対する何らかの予防措置をとることが有効であると考えられる。そこで、これらのコンピュータシステムへの侵入を防止するために、従来から種々の方策が提案されている。
【０００７】
この種の従来技術の例としては、例えば、文献「Ａｕｔｏｍａｔｉｃ Ｄｅｔｅｃｔｉｏｎ ａｎｄ Ｐｒｅｖｅｎｔｉｏｎ ｏｆ Ｂｕｆｆｅｒ−Ｏｖｅｒｆｌｏｗ Ａｔｔａｃｋｓ」（Ｃｒｉｓｐｉｎ Ｃｏｗａｎ， Ｃａｌｔｏｎ Ｐｕ， Ｄａｖｉｄ Ｍａｊｅｒ， Ｈｅａｔｈｅｒ Ｈｉｎｔｏｎ， Ｐｅａｔ Ｂａｋｋｅ， Ｓｔｅｖｅ Ｂｅａｔｔｉｅ， Ａａｒｏｎ Ｇｒｉｅｒ， Ｐｅｒｒｙ Ｗａｇｌｅ， ａｎｄ Ｑｉａｎ Ｚｈａｎｇ， ｉｎ ｔｈｅ ７ｔｈ ＵＳＥＮＩＸ Ｓｅｃｕｒｉｔｙ Ｓｙｍｐｏｓｉｕｍ， Ｓａｎ Ａｎｔｏｎｉｏ， ＴＸ， Ｊａｎｕａｒｙ １９９８．）に開示されたＳｔａｃｋＧｕａｒｄという技術がある。ＳｔａｃｋＧｕａｒｄでは、図９に示したようなスタック状態におけるリターンアドレスの領域と呼び出し元のフレームポインタの領域との間に、リターンアドレスの保護のための特別の値であるｇｕａｒｄ＿ｖａｌｕｅを挿入する。そして、関数のリターン処理において、ｇｕａｒｄ＿ｖａｌｕｅの有効性を確認することにより、攻撃の有無を確認する。
【０００８】
上記従来技術の他にも、仮想記憶のページを操作し、スタック上のリターンアドレス格納箇所を書き込み禁止にする手法や、リターンアドレス専用のスタックを別に作成し、関数の入口でリターンアドレスを専用スタックにコピーし、関数リターン処理で専用スタックから戻すことにより、リターンアドレスを保護する手法などが提案されている。また、バッファオーバーフローを原因とするあらゆる攻撃を防止するために、全ての配列アクセスに対して境界チェックを行うという手法も考えられる。
【０００９】
【発明が解決しようとする課題】
しかし、上述したコンピュータシステムへの侵入を防止するための従来技術は、次のような欠点を有している。
上記文献に記載されたＳｔａｃｋＧｕａｒｄは、実行中の関数の呼び出し元である直前の関数へのリターンアドレスと当該直前の関数におけるフレームポインタ（以下、ＰＦＰと略す）との間に、ｇｕａｒｄ＿ｖａｌｕｅを格納する。このため、リターンアドレスは保護されているが、変数スコープを指し示すフレームポインタは保護されていない。これにより、重大なセキュリティホールが存在している。
すなわち、フレームポインタを保護していないために、プログラムカウンタを操作することが可能である。以下に、その概要を説明する。
【００１０】
関数リターン処理では、次の各処理が行われる。
ＦＰ → ＳＰ
ＰＦＰ → ＦＰ
（ＳＰ） → ＰＣ ；ｒｅｔｕｒｎ ｏｐｅｒａｔｉｏｎ
ここで、ＦＰはフレームポインタ、ＳＰはスタックポインタ、ＰＣはプログラムカウンタである。また、矢印は値を代入することを示し、括弧は間接参照することを示す。
上記のように、ＳｔａｃｋＧｕａｒｄでは、スタック内のＰＦＰを保護していない。そのため、外部からの攻撃により、ＰＦＰの値を操作することが可能である。値の操作について、その伝搬を調べると、上記の関数リターン処理を参照すれば、ＰＦＰを操作することにより一度のリターンでフレームポインタを操作することができる。そして、二度目のリターンでプログラムカウンタを操作することができる。実際に悪意のあるコードを埋め込むには、ｇｕａｒｄ＿ｖａｌｕｅテストを通過させなくてはならないが、ＳｔａｃｋＧｕａｒｄがデフォルトで使用しているｇｕａｒｄ＿ｖａｌｕｅに対してはスタックスマッシング攻撃が可能である。そしてさらに、その他のｇｕａｒｄ＿ｖａｌｕｅについても攻撃手法が見つかる可能性がある。
したがって、ＳｔａｃｋＧｕａｒｄで用いられる従来の手法では、スタックスマッシング攻撃を完全に防止することができなかった。
【００１１】
また、ＳｔａｃｋＧｕａｒｄでは、一度目のリターンで汚されたフレームポインタの影響を検出するために、二度目のリターンでは必ずｇｕａｒｄ＿ｖａｌｕｅの有効性を確認しなくてはならない。そのため、全ての関数において、ｇｕａｒｄ＿ｖａｌｕｅの有効性を確認するプログラムを発生させている。したがって、ｇｕａｒｄ＿ｖａｌｕｅの有効性を確認する処理のために、必ずある程度のオーバーヘッドが発生していた。
さらにまた、ＳｔａｃｋＧｕａｒｄにおいては、リターンアドレス領域とＰＦＰ領域との間にｇｕａｒｄ＿ｖａｌｕｅを挿入するため、スタックのフレーム構造を変更することとなる。このため、ＳｔａｃｋＧｕａｒｄを実装したプログラムに対してデバッグ支援を行うことができなかった。
【００１２】
仮想記憶のページを操作し、スタック上のリターンアドレス格納箇所を書き込み禁止にする従来技術においては、リターンアドレスのみを保護し、フレームポインタを保護していないため、ＳｔａｃｋＧｕａｒｄと同様のセキュリティホールが存在し、スタックスマッシング攻撃を完全に防止することができなかった。
また、スタックページへの書き込みを行うときにはスーパーバイザーモードに制御が移るため、実行オーバーヘッドが大きいという欠点があった。
【００１３】
リターンアドレス専用のスタックを別に作成し、関数の入口でリターンアドレスを専用スタックにコピーし、関数リターン処理で専用スタックから戻す従来技術においては、リターンアドレスへの直接的な攻撃が可能であった。すなわち、グローバル変数領域に作成された専用スタックは、その値の有効性を確認しないで元のスタックに戻すため、専用スタックからリターンアドレスを戻す操作への攻撃が直接リターンアドレスへの攻撃となってしまう。
また、同従来技術は、専用スタックの管理オーバーヘッドが大きいという欠点があった。
【００１４】
全ての配列アクセスに対して境界チェックを行う場合は、上述したようにバッファオーバーフローを原因とするあらゆる攻撃を防止することができるが、主にポインタを使用したプログラムではオーバーヘッドが非常に大きいという欠点があった。
【００１５】
本発明は以上のような技術的課題を解決するためになされたものであって、スタック上のバッファオーバーフローを原因とするスタックスマッシング攻撃を完全に防止することを目的とする。
また、スタックスマッシング攻撃の防止手段を実装したことによる実行オーバーヘッドを削減することを他の目的とする。
【００１６】
【課題を解決するための手段】
かかる目的のもと、本発明は、コンピュータシステムが使用するメモリ装置であって、このコンピュータシステムがプログラムを実行する際の関数呼び出し後におけるこのメモリ装置のメモリパターンとして、実行中の関数の呼び出し元へのリターンアドレスを格納する領域と、この実行中の関数の呼び出し元へのプレヴィアス・フレームポインタを格納する領域と、このリターンアドレスを格納する領域とこのプレヴィアス・フレームポインタを格納する領域との後方に位置し、ローカル変数を格納する領域とを備え、このローカル変数を格納する領域は、このローカル変数を格納する領域に配列が格納されている場合に、この配列よりも前に、実行中の関数のリターン処理において破壊されていないかどうかを確認する対象であるガード変数を格納したメモリパターンを有することを特徴としている。このような構成とすれば、リターンアドレスと共にプレヴィアス・フレームポインタをも保護することにより、スタックスマッシング攻撃を用いたシステムへの侵入を確実に阻止することができる。
さらに、ガード変数を用いたスタック保護処理の対象を、ローカル変数を格納する領域に配列が格納されている場合に限定することにより、システム全体のオーバーヘッドを低減させることができる。
【００１７】
ここで、メモリ装置のメモリパターンにおけるローカル変数を格納する領域は、このローカル変数を格納する領域に文字配列が格納されている場合に、この配列よりも前に、ガード変数を格納する構成とすることができる。すなわち、ローカル変数を格納する領域に、配列のうちの文字配列が格納されている場合にのみ、ガード変数を用いたスタック保護処理を実行する。このような構成とすれば、文字配列を持たない関数の他に整数配列のような文字配列以外の配列を持つ関数に対してもガード変数を用いたスタック保護処理を行わないため、システム全体のオーバーヘッドを更に低減させることができる。
スタックスマッシング攻撃の対象となる配列は、主に文字配列であるため、ガード変数を用いたスタック保護処理の対象を文字配列を持つ関数のみに限定しても、安全性が大幅に損なわれることはない。そこで、処理速度が重視されるシステムでは、このような構成とすることが好ましい。
【００１８】
また、ローカル変数を格納する領域に格納されるガード変数として、乱数を用いる構成とすることができる。このほか、ガード変数としては、攻撃者が知ることのできない任意の値を用いることができる。
【００１９】
さらに本発明においては、コンピュータシステムが使用するメモリ装置であって、このコンピュータシステムがプログラムを実行する際の関数呼び出し後におけるこのメモリ装置のメモリパターンとして、実行中の関数の呼び出し元へのリターンアドレスを格納する領域と、このリターンアドレスを格納する領域の後方に位置し、実行中の関数の呼び出し元へのプレヴィアス・フレームポインタを格納する領域と、このプレヴィアス・フレームポインタを格納する領域の後方に位置し、ローカル変数を格納する領域とを備え、このローカル変数を格納する領域に配列が格納されている場合に、このプレヴィアス・フレームポインタとこの配列との間に、実行中の関数のリターン処理において破壊されていないかどうかを確認する対象であるガード変数を格納したメモリパターンを有することを特徴としている。すなわち、ガード変数を格納する位置は、スタック上のプレヴィアス・フレームポインタと配列との間であれば、どこでも良い。
【００２０】
また、本発明は、コンピュータによるプログラムの実行の際にスタックスマッシング攻撃からプログラムカウンタを保護するスタック保護システムであって、ソース形式のプログラムを入力し、関数呼び出し後のスタックにおけるプレヴィアス・フレームポインタとローカル変数としてこのスタックに格納される配列との間にガード変数を格納する指令をこのソース形式のプログラムに付加するスタック保護指令作成部と、このスタック保護指令作成部によりガード変数を格納する指令を付加されたプログラムを実行し、このガード変数を格納する指令にしたがって、関数呼び出しの際にスタックにこのガード変数を格納すると共に、この関数のリターン処理においてこのガード変数の有効性を確認するスタック保護処理実行部とを備えることを特徴としている。このような構成とすれば、プログラムを実行する際に、リターンアドレスと共にプレヴィアス・フレームポインタをも保護することができ、スタックスマッシング攻撃を用いたシステムへの侵入を確実に阻止することができる点で優れている。
【００２１】
ここで、スタック保護処理実行部は、関数のリターン処理においてガード変数が破壊されていることを検出した場合に、プログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知する異常終了処理を行う構成とすることができる。このような構成とすれば、スタックスマッシング攻撃が行われた場合には、かかる関数の呼び出し元へ処理が戻る直前でプログラムの実行を中止するため、システムへの侵入を効果的に防止することができる点で好ましい。
【００２２】
また、スタック保護指令作成部は、コンパイラに実装され、このコンパイラが、ソース形式のプログラムとしてコンパイラ言語にて記述されたソースプログラムを入力し、このソースプログラムをオブジェクトプログラムに翻訳する際に、このオブジェクトプログラムに対して、ガード変数を格納する指令を付加する構成とすることができる。このような構成とすれば、オーバーフローを引き起こす変数よりもスタック上で上位アドレスにガード変数の宣言を配置すること、及び全ての関数の出口にプログラムを挿入することが容易となる点で好ましい。
【００２３】
さらに本発明においては、コンピュータによるプログラムの実行の際にスタックスマッシング攻撃からプログラムカウンタを保護するスタック保護システムであって、関数を実行する際にスタック上におけるプレヴィアス・フレームポインタとローカル変数としてスタックに格納される配列との間にガード変数を格納する指令が付加されたプログラムを入力して実行すると共に、このガード変数を格納する指令にしたがって、関数呼び出しの際にスタックに前記ガード変数を格納し、この関数のリターン処理においてこのガード変数の有効性を確認するプログラム実行手段と、このプログラム実行手段により、関数のリターン処理においてこのガード変数が破壊されていることが検出された場合に、プログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知する異常終了処理を行う異常終了実行手段とを備えることを特徴としている。このような構成とすれば、手作業を含むどのような手段でプログラムにガード変数を格納する指令を付加した場合であっても、そのようなプログラムを実行する際にスタック保護を実行できる点で好ましい。
【００２４】
また、本発明は、種々の演算処理を行うデータ処理装置と、このデータ処理装置が演算処理を行う際に用いるメモリ装置とを備えたコンピュータシステムであって、このデータ処理装置が演算処理を実行する際の関数呼び出し後におけるこのメモリ装置のメモリパターンは、実行中の関数の呼び出し元へのリターンアドレスを格納する領域と、実行中の関数の呼び出し元へのプレヴィアス・フレームポインタを格納する領域と、このリターンアドレスを格納する領域とこのプレヴィアス・フレームポインタを格納する領域との後方に位置し、ローカル変数を格納する領域とを備え、このローカル変数を格納する領域は、このローカル変数を格納する領域に配列が格納されている場合に、この配列よりも前に、実行中の関数のリターン処理において破壊されていないかどうかを確認する対象であるガード変数を格納したことを特徴としている。このような構成とすれば、リターンアドレスと共にプレヴィアス・フレームポインタをも保護することにより、スタックスマッシング攻撃を用いたシステムへの侵入を確実に阻止することができる。さらに、ガード変数を用いたスタック保護処理の対象を、ローカル変数を格納する領域に配列が格納されている場合に限定することにより、システム全体のオーバーヘッドを低減させることができる。
【００２５】
また、本発明は、種々の演算処理を行うデータ処理装置と、このデータ処理装置が演算処理を行う際に用いるメモリ装置とを備えたコンピュータシステムであって、このデータ処理装置が演算処理を実行する際の関数呼び出し後におけるこのメモリ装置のメモリパターンは、実行中の関数の呼び出し元へのリターンアドレスを格納する領域と、このリターンアドレスを格納する領域の後方に位置し、実行中の関数の呼び出し元へのプレヴィアス・フレームポインタを格納する領域と、このプレヴィアス・フレームポインタを格納する領域の後方に位置し、ローカル変数を格納する領域とを備え、このローカル変数を格納する領域に配列が格納されている場合に、このプレヴィアス・フレームポインタとこの配列との間に、実行中の関数のリターン処理において破壊されていないかどうかを確認する対象であるガード変数を格納したことを特徴としている。ガード変数を格納する位置は、スタック上のプレヴィアス・フレームポインタと配列との間であれば、どこでも良い。
【００２６】
さらにまた、本発明は、プログラム制御により種々の演算処理を行うコンピュータシステムであって、関数を実行する際にスタック上におけるプレヴィアス・フレームポインタとローカル変数としてスタックに格納される配列との間にガード変数を格納する指令が付加されたプログラムを読み込んで実行するデータ処理装置と、このデータ処理装置が演算処理を行う際に用いるメモリ装置とを備え、このデータ処理装置は、前記ガード変数を格納する指令が付加されたプログラムにおけるガード変数を格納する指令にしたがって、関数呼び出しの際に、メモリ装置上のスタックにこのガード変数を格納すると共に、この関数のリターン処理においてこのガード変数の有効性を確認することを特徴としている。このような構成とすれば、ガード変数を格納する指令が付加されたプログラムを、磁気ディスクや光ディスクなどの種々の記憶媒体に記録して提供したり、ネットワークを介して提供したりすることにより、このプログラムをインストールしたコンピュータシステムにおいて、スタック保護を実行できる点で好ましい。
【００２７】
ここで、データ処理装置は、関数のリターン処理においてガード変数が破壊されていることを検出した場合に、このプログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知する異常終了処理を行うことを特徴としている。このような構成とすれば、スタックスマッシング攻撃が行われた場合には、かかる関数の呼び出し元へ処理が戻る直前でプログラムの実行を中止するため、システムへの侵入を効果的に防止することができる点で好ましい。
【００２８】
また、本発明は、プログラム制御により種々の演算処理を行うコンピュータシステムであって、ソース形式のプログラムを入力し、関数呼び出し後のスタックにおけるプレヴィアス・フレームポインタとローカル変数としてこのスタックに格納される配列との間にガード変数を格納する指令をこのソース形式のプログラムに付加すると共に、このガード変数を格納する指令を付加されたプログラムを実行するデータ処理装置と、このデータ処理装置が演算処理を行う際に用いるメモリ装置とを備え、このデータ処理装置は、このガード変数を格納する指令を付加されたプログラムにおけるガード変数を格納する指令にしたがって、関数呼び出しの際に、このメモリ装置上のスタックにこのガード変数を格納すると共に、この関数のリターン処理においてこのガード変数の有効性を確認することを特徴としている。このような構成とすれば、任意のプログラムに対して、ガード変数を格納する指令を付加し、このプログラムを実行することによって、スタックスマッシング攻撃を用いたシステムへの侵入を確実に阻止することができる点で優れている。ここで、プログラムは、コンパイラ言語で記述されたものであっても、インタプリタ言語で記述されたものであってもかまわない。コンパイラ言語で記述されたプログラムである場合は、データ処理装置は、コンパイラとしての機能も併せて有することとなる。
【００２９】
ここで、データ処理装置は、関数のリターン処理においてガード変数が破壊されていることを検出した場合に、このプログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知する異常終了処理を行うことを特徴としている。このような構成とすれば、スタックスマッシング攻撃が行われた場合には、かかる関数の呼び出し元へ処理が戻る直前でプログラムの実行を中止するため、システムへの侵入を効果的に防止することができる点で好ましい。
【００３０】
また、本発明は、ソースプログラムを入力しオブジェクトプログラムに翻訳して出力するコンパイラであって、プログラムを翻訳する翻訳手段と、プログラムの翻訳の際に、サブルーチンごとに、このサブルーチンに含まれる関数が配列を持っているかどうかを調べ、配列を持っている場合に、このサブルーチンに対して、この関数を実行する際のスタックにおいてプレヴィアス・フレームポインタとローカル変数としてこのスタックに格納される配列との間にガード変数を格納すると共に、関数のリターン処理においてこのガード変数の有効性を確認する旨の指令を付加するスタック保護指令付加手段とを備えることを特徴としている。このような構成とすれば、ソースプログラムをコンパイルした時点で必要な指令をプログラムに付加することができる点で優れている。
【００３１】
さらにまた、本発明は、コンピュータによるプログラムの実行の際にスタックスマッシング攻撃からプログラムカウンタを保護するスタック保護方法であって、ソース形式のプログラムに対して、関数呼び出し後のスタックにおけるプレヴィアス・フレームポインタとローカル変数としてこのスタックに格納される配列との間にガード変数を格納する指令をこのソース形式のプログラムに付加するステップと、このガード変数を格納する指令を付加されたプログラムを実行すると共に、このガード変数を格納する指令にしたがって、関数呼び出しの際にスタックにこのガード変数を格納し、関数のリターン処理においてこのガード変数の有効性を確認するステップと、この関数のリターン処理においてこのガード変数が破壊されていることが検出された場合に、このプログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知するステップとを含むことを特徴としている。
【００３２】
同様にして、コンピュータによるプログラムの実行の際にスタックスマッシング攻撃からプログラムカウンタを保護するスタック保護方法であって、関数を実行する際にスタック上におけるプレヴィアス・フレームポインタとローカル変数としてスタックに格納される配列との間にガード変数を格納する指令が付加されたプログラムを実行すると共に、このガード変数を格納する指令にしたがって、関数呼び出しの際にスタックにこのガード変数を格納し、関数のリターン処理においてこのガード変数の有効性を確認するステップと、関数のリターン処理においてこのガード変数が破壊されていることが検出された場合に、このプログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知するステップとを含む構成とすることができる。このような構成とすれば、手作業を含むどのような手段でプログラムにガード変数を格納する指令を付加した場合であっても、そのようなプログラムを実行する際にスタック保護を実行できる点で好ましい。
【００３３】
また、本発明は、コンピュータに実行させるプログラムを当該コンピュータの入力手段が読取可能に記憶した記憶媒体において、このプログラムは、配列を持っている関数を実行する際のスタックにおいてプレヴィアス・フレームポインタとローカル変数としてこのスタックに格納される配列との間にガード変数を格納する処理と、関数のリターン処理においてこのガード変数の有効性を確認する処理と、関数のリターン処理においてこのガード変数が破壊されていることが検出された場合に、このプログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知する処理とをこのコンピュータに実行させることを特徴としている。このような構成とすれば、このプログラムを実行する全てのシステムにおいて、スタックスマッシング攻撃からプログラムカウンタを保護できる点で好ましい。
なお、このプログラムは、その種類において何ら制限はなく、コンパイラ言語であってもインタプリタ言語であっても良い。
【００３４】
さらにまた、本発明は、コンピュータに、配列を持っている関数を実行する際のスタックにおいてプレヴィアス・フレームポインタとローカル変数としてこのスタックに格納される配列との間にガード変数を格納する処理と、関数のリターン処理においてこのガード変数の有効性を確認する処理と、関数のリターン処理においてこのガード変数が破壊されていることが検出された場合に、このプログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知する処理とを実行させるプログラムを記憶する記憶手段と、この記憶手段からこのプログラムを読み出してこのプログラムを送信する送信手段とを備えたことを特徴としている。このような構成とすれば、このプログラム伝送装置からこのプログラムをダウンロードしてインストール可能なあらゆるシステムにおいて、スタックスマッシング攻撃からプログラムカウンタを保護できる。
【００３５】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいてこの発明を詳細に説明する。
まず、本発明の概要を説明する。本発明では、プログラムを実行する際のメモリパターン（記憶域の割当て）において、スタック上のプレヴィアス・フレームポインタ（Ｐｒｅｖｉｏｕｓ ｆｒａｍｅ ｐｏｉｎｔｅｒ：ＰＦＰ）とローカル変数領域における配列との間に、スタックスマッシング攻撃からプログラムカウンタを保護するための特別な値であるガード変数を挿入する。そして、関数リターン処理において、ガード変数の有効性を確認することにより、スタックスマッシング攻撃の有無を確認する。
スタックスマッシング攻撃においては、ローカル変数への代入操作を行い、境界チェックが不完全な場合に、そのローカル変数より上位のスタック領域を破壊する。したがって、プレヴィアス・フレームポインタと配列との間にガード変数を挿入されたスタックに対して、スタックスマッシング攻撃が行われると、関数の出口でガード変数が破壊されていることが検出される。この時点でプログラムの実行を止めることにより、当該関数の呼び出し元へのリターンアドレス及びプレヴィアス・フレームポインタを保護することができ、当該システムへの侵入を阻止することができる。
【００３６】
図１は、本実施の形態におけるスタック保護システムの全体構成を説明する図である。図１において、符号１１１はソース形式のプログラムである。符号１１２はスタック保護指令作成部であり、ソース形式のプログラム１１１における所定の箇所にガード変数を格納するための指令を作成してプログラムに付加する。符号１２１は、ガード変数を格納するための処理指令とガード変数の格納位置とを付加されたプログラムである。符号１３１はスタックであり、コンピュータのメモリ装置におけるメモリパターンを形成する。符号１３２はスタック保護処理実行部であり、プログラム１２１を実行すると共に、その際にプログラム１２１に付加されている処理指令及びガード変数の格納位置に基づいてスタックの保護処理を実行する。符号１３３は保護数値であり、ガード変数として用いられる値である。
【００３７】
図２は、コンピュータにおいて、本実施の形態によりスタックの保護処理が実行されている場合におけるメモリ装置のスタックの状態（メモリパターン）を示す図である。図２に示すように、スタックトップ（図では下側）から順に、ローカル変数領域２１０、プレヴィアス・フレームポインタ（ＰＦＰ）２２０、及び当該呼び出し元へのリターンアドレス（ＲＡ）２３０が積まれている。そして、ローカル変数領域２１０における配列２１１の前、すなわち、配列２１１とプレヴィアス・フレームポインタ（ＰＦＰ）２２０との間にガード変数（Ｇ）２１２が格納されている。ガード変数（Ｇ）２１２の位置は、配列２１１とプレヴィアス・フレームポインタ（ＰＦＰ）２２０との間であればよく、この位置に格納される他のローカル変数との前後関係は問わない。
【００３８】
図３は、図１に示したスタック保護システムにおけるスタック保護指令作成部１１２の処理を説明するフローチャートである。スタック保護指令作成部１１２は、ソース形式のプログラム１１１のサブルーチンごとに、図３に示す処理を実行する。図３を参照すると、スタック保護指令作成部１１２は、まず着目中のサブルーチンにおいて、ローカル変数として配列が使用されているかどうかを確認する（ステップ３０１）。
そして、配列が使用されている場合は、ガード変数（Ｇ）の格納位置を決定する（ステップ３０２）。ここで、ガード変数（Ｇ）の格納位置は、上述したように、プレヴィアス・フレームポインタと配列との間の任意の位置である。次に、当該サブルーチンを実行する際に、スタックにおける、ステップ３０２で決定された当該ガード変数（Ｇ）の格納位置にガード変数（Ｇ）を格納する旨の処理指令を生成する（ステップ３０３）。
以上のようにして、ガード変数を格納するための処理指令とガード変数の格納位置とを付加されたプログラム１２１が出力される。
【００３９】
プログラム１２１には、実際には、ガード変数を挿入すべきサブルーチン（関数）ごとに、ガード変数の宣言、関数の入口におけるガード変数の値の設定、関数の出口におけるガード変数の値の確認及び異常終了を実行するための命令が埋め込まれることとなる。このプログラム１２１の具体的な構成例は後述する。
【００４０】
図４は、スタック保護処理実行部１３２の処理を説明するフローチャートである。スタック保護処理実行部１３２は、スタック保護指令作成部１１２によりガード変数を格納するための処理指令とガード変数の格納位置とを付加されたプログラム１２１のサブルーチンごとに、図４に示す処理を実行する。図４を参照すると、まずプログラム１２１の着目中のサブルーチンにおいて、スタック保護指令作成部１１２により付加された処理指令があるかどうかを調べる（ステップ４０１）。
そして、処理指令がある場合は、当該プログラム１２１に処理指令と共に付加されているガード変数（Ｇ）格納位置に対応するスタック１３１上の位置にガード変数（Ｇ）の格納領域を生成する（ステップ４０２）。上述したように、ガード変数（Ｇ）の格納領域は、スタック１３１上のローカル変数領域であって、配列よりも前の位置に生成される。
【００４１】
次に、ステップ４０２で生成されたガード変数（Ｇ）の格納領域に、保護数値１３３を格納する（ステップ４０３）。これにより、スタック１３１は、図２に示した状態となる。ガード変数（Ｇ）として格納される保護数値１３３の内容は、特に制約はないが、攻撃者が推定できない値や攻撃によって格納することのできない値とする。そのような値の例として乱数を利用することができる。
【００４２】
次に、当該サブルーチンの処理（関数）を実行する（ステップ４０４）。そして、関数の出口でガード変数（Ｇ）として格納した値が保持されているかどうかを確認する（ステップ４０５）。ガード変数（Ｇ）の値が保持されていれば、通常通り終了する。また、ガード変数（Ｇ）の値が保持されていない場合は、スタックスマッシング攻撃が行われたことを意味するので、攻撃があったことを示すメッセージ及びエラーログを出力してプログラムを終了する（ステップ４０６）。
以上のようにして、スタックスマッシング攻撃があれば、リターン処理の直前で検出でき、コンピュータシステムへの侵入を防止できることとなる。
【００４３】
本実施の形態のスタック保護システムは、結果的にプログラムの実行段階において、メモリパターンとして、図２に示したように、スタック上のプレヴィアス・フレームポインタと配列との間にガード変数を配置できれば良い。したがって、本実施の形態によるスタック保護システムを実現するにあたり、プログラミング言語の種類やシステムの形態に応じて、種々の態様を採ることができる。例えば、プログラミング言語がコンパイラ言語である場合は、スタック保護指令作成部１１２の機能をコンパイラに実装することができる。この場合、スタック保護指令作成部１１２により処理指令及びガード変数（Ｇ）の格納位置を付加されたプログラム１２１は、実行形式のプログラムとなる。コンパイラのコード生成時にガード変数を挿入するためのプログラムを埋め込むこととすれば、オーバーフローを引き起こす変数よりもスタック上で上位アドレスにガード変数の宣言を配置すること、及び全ての関数の出口にプログラムを挿入することが容易となる点で好ましい。
【００４４】
これに対し、プログラミング言語がインタプリタ言語である場合は、スタック保護指令作成部１１２により処理指令及びガード変数（Ｇ）の格納位置を付加されたプログラム１２１の段階では、未だソース形式のプログラムである。
また、プログラミング言語がコンパイラ言語である場合であっても、コンパイラの前段にスタック保護指令作成部１１２を構成する処理装置を置き、ソースプログラムの段階でガード変数を挿入するためのプログラムを埋め込むようにしても良い。図１０に示したＣ言語のソースプログラムに対してガード変数を挿入するためのプログラムを埋め込む例を図５及び図６を参照して説明する。
この場合、スタック保護指令作成部１１２は、図５に示す３つのプログラムを、図１０のプログラムの変数宣言部、関数の入口、関数の出口にそれぞれ挿入する。各プログラムが挿入された状態が図６に示すプログラムである。図６を参照すると、変数宣言部である符号６０１の位置、関数の入口である符号６０２の位置、関数の出口である符号６０３の位置に、それぞれ図５に示した３つのプログラムが挿入されている。
【００４５】
このように、スタック保護システムを実現するには、プログラミング言語の種類やシステムの形態に応じて、種々の態様を採ることが可能である。上記の他にも、ソース形式のプログラムを作成する段階で、所望の関数に対して、手作業により図５に示したようなプログラムを書き込むことも可能である。この場合、スタック保護指令作成部１１２の処理が手作業にて行われることに相当する。したがって、作成されたプログラムは最初からプログラム１２１の状態であり、スタック保護システムとしては、スタック保護処理実行部１３２による処理だけが実行されることとなる。
【００４６】
図７は、本実施の形態のスタック保護システムを適用したコンピュータシステムの構成例を説明する図である。図７に示すコンピュータシステム７００は、データ処理を行うデータ処理装置７１０と、データ処理装置７１０による処理の際に用いられるメモリ装置７２０と、データ処理装置７１０を制御する制御プログラム７３１を格納した記憶装置７３０とを備える。
ＣＰＵにて実現されるデータ処理装置７１０は、制御プログラム７３１の制御の下、スタック保護処理実行部１３２の機能を実現する。メモリ装置７２０は、スタック保護処理実行部１３２による関数の実行において、スタック７２１上に、図２に示したガード変数を含むメモリパターンを形成する。さらに、データ処理装置７１０のスタック保護処理実行部１３２は、メモリ装置７２０のスタック７２１上に図２に示したメモリパターンを形成する際に、ガード変数の値として、記憶装置７３０から読み出した保護数値１３３を挿入する。
なお、コンピュータシステム７００において、コンパイラ言語が実行される場合は、制御プログラム７３１は、図１に示したプログラム１２１に相当する実行形式のプログラムとなる。また、記憶装置７３０に格納された制御プログラム７３１を、ガード変数を格納するための処理指令とガード変数の格納位置とを付加されたソース形式のプログラムとすることもできる。この場合、データ処理装置７１０は、コンパイラの機能を併せて備えることとなる。さらに、制御プログラム７３１を、ガード変数を格納するための処理指令とガード変数の格納位置とを付加する前のソース形式のプログラムとすることもできる。この場合、制御プログラム７３１は、図１に示したソース形式のプログラム１１１に相当し、データ処理装置７１０は、スタック保護指令作成部１１２の機能を更に備えることとなる。さらにまた、図７においては、メモリ装置７２０と記憶装置７３０とを別個の構成要素として記載したが、物理的には単一の記憶モジュールにて構成することができる。
【００４７】
次に、本実施の形態におけるオーバーフローの低減について説明する。
変数の型宣言とその参照とが正しく対応しているプログラムにおいては、バッファオーバーフローが発生する変数は、サイズ情報を持たない配列である。Ｃ言語などで使用されるこのような配列は、サイズ情報がないため、コンパイラの型チェックだけではバッファオーバーフローを防ぐことができない。一方、配列以外の変数では、プログラミング作法として型変換に注意を払えば、バッファオーバーフローを防ぐことが可能である。
したがって、上述したように本実施の形態では、図２に示したように、スタックのローカル変数領域における配列とプレヴィアス・フレームポインタとの間にガード変数を格納し、ローカル変数として配列を持たない場合はガード変数を格納しないこととした。これにより、システム全体のオーバーヘッドの低減を図ることができる。
【００４８】
ここで、変数の型宣言とその参照とが正しく対応しているプログラムにおいて、テスト領域に配列を持っていない関数（ＡＦ関数と称す）では、ガード変数を用いたバッファオーバーフローのテストを行う必要がないことを証明する。
図８は、スタックにおけるテスト領域を説明する図である。スタック上のガード変数を用いてバッファオーバーフローのテストを行う領域は、当該ガード変数とそれよりも下位に現れるガード変数との間の領域、すなわち、図８の斜線を付した領域である。この領域を関数のテスト領域８０１と呼ぶこととする。証明は次の２つのステップで行う。
１．ＡＦ関数のテスト領域８０１が破壊されるのは、それ以降に呼ばれる関数のテスト領域８０１がバッファオーバーフローを起こした場合であり、またその場合だけであることを示す。
２．ＡＦ関数のテスト領域８０１が破壊された場合は、ＡＦ関数に実行制御が戻らないことを示す。
【００４９】
まず、第１のステップについて説明する。ＡＦ関数のテスト領域８０１には配列は存在しない。したがって、テスト領域８０１が破壊されたとしても、当該テスト領域がバッファオーバーフローの発生源ではない。したがって、テスト領域８０１の破壊の原因は、スタック上の当該関数フレームの上に置かれたテスト領域８０１となる。すなわち、ＡＦ関数から呼び出された関数の中でバッファオーバーフローが生じ、スタックの上位アドレスの向きに破壊して、ＡＦ関数のテスト領域を壊したものである。
【００５０】
次に、第２のステップについて説明する。第１のステップにより、ＡＦ関数のテスト領域８０１の破壊原因は、それ以降に呼ばれる他の関数にある。また上述したように、変数の型宣言とその参照とが正しく対応しているプログラムにおいては、バッファオーバーフローが発生する変数は配列であるから、ＡＦ関数におけるテスト領域８０１の破壊の原因となった領域は、配列である。配列を定義した関数では、ガード変数を用いたバッファオーバーフローのテストが実行されている。そして、テスト領域８０１を破壊し、かつリターンアドレスを操作するような攻撃があった場合は、必ずガード変数が破壊される。そのため、当該関数のリターン処理でプログラムは停止する。したがって、ＡＦ関数まで実行制御が戻ることはない。
【００５１】
以上で、テスト領域８０１に配列を持っていないＡＦ関数では、ガード変数を用いたバッファオーバーフローのテストを行う必要がないことが証明された。
なお、本実施の形態では、配列一般に対してガード変数を用いたスタック保護を行うこととして説明したが、特に文字配列のみを対象としてガード変数を用いたスタック保護を行うこととしても良い。これは、スタックスマッシング攻撃の対象となる配列が主に文字配列だからである。さらにその理由は、文字配列が、プログラム外部の情報表現に使用すること、データサイズを確認せずに処理できるように終端記号を持つ表現であること、といった特徴を持つことにある。
したがって、ガード変数を用いたスタック保護を行う関数を、ローカル変数として文字配列を持つものに限定し、文字配列を持たないもの及び整数配列のような文字配列以外の配列を持つものについては、ガード変数を格納しないことにより、システム全体のオーバーヘッドを更に低減させることができる。
【００５２】
以上のように、本実施の形態では、関数のリターン処理において、スタックのプレヴィアス・フレームポインタと配列との間に格納されたガード変数の有効性を確認する。これにより、スタック上のバッファオーバーフローを原因とするスタックスマッシング攻撃に関しては、ネットワーク経由での攻撃及びローカルユーザからの攻撃のいずれに対しても防止することができる。
【００５３】
また、本実施の形態では、ローカル変数として配列を持つ関数のみを対象としてガード変数を用いたスタック保護を実行するため、従来技術において説明したように、全ての関数に対してスタック保護のための処理を実行する場合と比べてオーバーヘッドの削減を図ることができる。特にリターンアドレスの格納箇所を書き込み禁止にする場合や、リターンアドレス専用のスタックを用意する場合と比べると、大幅なオーバーヘッドの削減を実現できる。
さらに、ローカル変数として文字配列を持つ関数のみを対象としてガード変数を用いたスタック保護を行うこととすれば、さらなるオーバーヘッドの削減を図ることができる。
【００５４】
なお、本実施の形態では、上述したようにガード変数をローカル変数領域に格納するため、スタックのフレーム構造を変更することがない。したがって、プログラムに対するデバッガによるデバッグ支援処理を行うことができなくなると行った不都合もない。
【００５５】
【発明の効果】
以上説明したように、本発明によれば、スタック上のバッファオーバーフローを原因とするスタックスマッシング攻撃を完全に防止することができる。
また、スタックスマッシング攻撃の防止手段を実装したことによる実行オーバーヘッドを削減することができる。
【図面の簡単な説明】
【図１】本実施の形態におけるスタック保護システムの全体構成を説明するための図である。
【図２】本実施の形態によりスタックの保護処理が実行されている場合のスタックの状態（メモリパターン）を示す図である。
【図３】本実施の形態におけるスタック保護指令作成部の処理を説明するフローチャートである。
【図４】本実施の形態におけるスタック保護処理実行部の処理を説明するフローチャートである。
【図５】本実施の形態においてスタック保護の対象とすべきプログラムに挿入する、スタック保護を実行するためのプログラムの例を示す図である。
【図６】図１０のプログラムに対して図５のプログラムを挿入した状態を示す図である。
【図７】本実施の形態のスタック保護システムを適用したコンピュータシステムの構成例を説明する図である。
【図８】スタックにおけるテスト領域を説明する図である。
【図９】Ｃ言語における関数呼び出し後のスタック状態を説明する図である。
【図１０】Ｃ言語で記述されたプログラムの例を示す図である。
【図１１】図１０のプログラムに対してスタックスマッシング攻撃が行われた場合のスタックの状態を説明する図である。
【符号の説明】
１１１…ソース形式のプログラム、１１２…スタック保護指令作成部、１２１…プログラム、１３１…スタック、１３２…スタック保護処理実行部、１３３…保護数値、７００…コンピュータシステム、７１０…データ処理装置、７２０…メモリ装置、７２１…スタック、７３０…記憶装置、７３１…制御プログラム、８０１…テスト領域
【発明の属する技術分野】
本発明は、スタックスマッシング攻撃によるコンピュータへの侵入からプログラムカウンタを保護するスタック保護方法に関する。
【０００２】
【従来の技術】
コンピュータシステムヘの侵入は、一般に、システム設定の不備やセキュリティホールと呼ばれるシステムの弱点を攻撃して他人の権限で侵入し、次の攻撃でシステム管理者権限を得るといった手順で行われる。
【０００３】
このような攻撃の典型的なものとしてスタックスマッシング攻撃がある。スタックには、プログラム内のサブルーチンの実行状態を保持するために、サブルーチンのリターンアドレス、ローカル変数、引数などが保管される。そして、スタックスマッシング攻撃は、スタック内のリターンアドレスを書き換えることによって悪意のあるプログラムに実行制御を移すという手法である。
【０００４】
スタックの構造を示してスタックスマッシング攻撃について具体的に説明する。図９はＣ言語における関数呼び出し後のスタック状態を示している。図９を参照すると、スタックトップ（図では下側）から順に、ローカル変数（Ｌｏｃａｌ Ｖａｒｉａｂｌｅ：ＬＶ）、当該関数の呼び出し元である直前の関数のフレームポインタ（Ｐｒｅｖｉｏｕｓ ｆｒａｍｅ ｐｏｉｎｔｅｒ：ＰＦＰ）、及び当該呼び出し元へのリターンアドレス（Ｒｅｔｕｒｎ Ａｄｄｒｅｓｓ：ＲＡ）が積まれている。ここで、フレームポインタ（ｆｒａｍｅ ｐｏｉｎｔｅｒ：ＦＰ）とは、ローカル変数が相対参照される際のベースポインタの事である。スタックスマッシング攻撃においては、ローカル変数（特に配列）への代入操作を行い、境界チェックが不完全な場合に、そのローカル変数より上位のスタック領域を破壊する。そして、スタック領域を破壊する際に、プログラムを書き込むと共に、リターンアドレスの領域にそのプログラムを指すような値を書き込む。この状態で関数のリターン処理が行われると、書き込まれたプログラムが起動することとなる。
【０００５】
Ｃ言語で記述されたプログラムを例にして、スタックスマッシング攻撃について、さらに具体的に説明する。図１０はスタックスマッシング攻撃の攻撃対象であるＣ言語で記述されたプログラムの例であり、図１１はこのプログラムに対してスタックスマッシング攻撃が行われた場合のスタックの状態を説明する図である。図１０において、関数ｆｏｏは環境変数ＨＯＭＥの内容をローカル変数にコピーするプログラムである。関数ｓｔｒｃｐｙはローカル変数の大きさを考慮しないため、環境変数ＨＯＭＥの内容が１２８文字以上である場合、図１１のｂｕｆから上方向の内容（網掛け箇所）を壊すことになる。この破壊内容にプログラムを埋め込み、かつリターンアドレスの領域にそのプログラムの先頭アドレスを置くことによって、埋め込んだプログラムへ制御を移すことができる。
【０００６】
上述したスタックスマッシング攻撃などにより、他人の管理するコンピュータネットワークに侵入する行為は、それ自体が機密漏洩やシステム破壊などを引き起こす場合がある。また、他人のＩＤやパスワードを盗み、その正当な所有者のふりをしてシステムに侵入するなりすまし行為や、他のコンピュータに侵入するための足がかりとして利用される場合もある。
従来、この種のスタックスマッシング攻撃は、ＵＮＩＸサーバを主な攻撃目標としていた。しかし最近では、ＡｃｔｉｖｅＸ（Ａｃｒｏｂａｔ Ｃｏｎｔｒｏｌ ｆｏｒ ＡｃｔｉｖｅＸなど（なお、ＡｃｔｉｖｅＸは米国マイクロソフト・コーポレーションの商標）のバッファオーバーフローが問題となり、これを対象とする攻撃が行われるようになっている。そのため、ネットワークに接続するコンピュータ一般、すなわち、サーバマシン、クライアントマシン、ＰＤＡなどの全てが攻撃目標となり得る。
バッファオーバーフローを起こすバグは、発見されてから取り除かれるというのが一般的である。したがって、このバグに対する攻撃を防ぐには、そのような攻撃に対する何らかの予防措置をとることが有効であると考えられる。そこで、これらのコンピュータシステムへの侵入を防止するために、従来から種々の方策が提案されている。
【０００７】
この種の従来技術の例としては、例えば、文献「Ａｕｔｏｍａｔｉｃ Ｄｅｔｅｃｔｉｏｎ ａｎｄ Ｐｒｅｖｅｎｔｉｏｎ ｏｆ Ｂｕｆｆｅｒ−Ｏｖｅｒｆｌｏｗ Ａｔｔａｃｋｓ」（Ｃｒｉｓｐｉｎ Ｃｏｗａｎ， Ｃａｌｔｏｎ Ｐｕ， Ｄａｖｉｄ Ｍａｊｅｒ， Ｈｅａｔｈｅｒ Ｈｉｎｔｏｎ， Ｐｅａｔ Ｂａｋｋｅ， Ｓｔｅｖｅ Ｂｅａｔｔｉｅ， Ａａｒｏｎ Ｇｒｉｅｒ， Ｐｅｒｒｙ Ｗａｇｌｅ， ａｎｄ Ｑｉａｎ Ｚｈａｎｇ， ｉｎ ｔｈｅ ７ｔｈ ＵＳＥＮＩＸ Ｓｅｃｕｒｉｔｙ Ｓｙｍｐｏｓｉｕｍ， Ｓａｎ Ａｎｔｏｎｉｏ， ＴＸ， Ｊａｎｕａｒｙ １９９８．）に開示されたＳｔａｃｋＧｕａｒｄという技術がある。ＳｔａｃｋＧｕａｒｄでは、図９に示したようなスタック状態におけるリターンアドレスの領域と呼び出し元のフレームポインタの領域との間に、リターンアドレスの保護のための特別の値であるｇｕａｒｄ＿ｖａｌｕｅを挿入する。そして、関数のリターン処理において、ｇｕａｒｄ＿ｖａｌｕｅの有効性を確認することにより、攻撃の有無を確認する。
【０００８】
上記従来技術の他にも、仮想記憶のページを操作し、スタック上のリターンアドレス格納箇所を書き込み禁止にする手法や、リターンアドレス専用のスタックを別に作成し、関数の入口でリターンアドレスを専用スタックにコピーし、関数リターン処理で専用スタックから戻すことにより、リターンアドレスを保護する手法などが提案されている。また、バッファオーバーフローを原因とするあらゆる攻撃を防止するために、全ての配列アクセスに対して境界チェックを行うという手法も考えられる。
【０００９】
【発明が解決しようとする課題】
しかし、上述したコンピュータシステムへの侵入を防止するための従来技術は、次のような欠点を有している。
上記文献に記載されたＳｔａｃｋＧｕａｒｄは、実行中の関数の呼び出し元である直前の関数へのリターンアドレスと当該直前の関数におけるフレームポインタ（以下、ＰＦＰと略す）との間に、ｇｕａｒｄ＿ｖａｌｕｅを格納する。このため、リターンアドレスは保護されているが、変数スコープを指し示すフレームポインタは保護されていない。これにより、重大なセキュリティホールが存在している。
すなわち、フレームポインタを保護していないために、プログラムカウンタを操作することが可能である。以下に、その概要を説明する。
【００１０】
関数リターン処理では、次の各処理が行われる。
ＦＰ → ＳＰ
ＰＦＰ → ＦＰ
（ＳＰ） → ＰＣ ；ｒｅｔｕｒｎ ｏｐｅｒａｔｉｏｎ
ここで、ＦＰはフレームポインタ、ＳＰはスタックポインタ、ＰＣはプログラムカウンタである。また、矢印は値を代入することを示し、括弧は間接参照することを示す。
上記のように、ＳｔａｃｋＧｕａｒｄでは、スタック内のＰＦＰを保護していない。そのため、外部からの攻撃により、ＰＦＰの値を操作することが可能である。値の操作について、その伝搬を調べると、上記の関数リターン処理を参照すれば、ＰＦＰを操作することにより一度のリターンでフレームポインタを操作することができる。そして、二度目のリターンでプログラムカウンタを操作することができる。実際に悪意のあるコードを埋め込むには、ｇｕａｒｄ＿ｖａｌｕｅテストを通過させなくてはならないが、ＳｔａｃｋＧｕａｒｄがデフォルトで使用しているｇｕａｒｄ＿ｖａｌｕｅに対してはスタックスマッシング攻撃が可能である。そしてさらに、その他のｇｕａｒｄ＿ｖａｌｕｅについても攻撃手法が見つかる可能性がある。
したがって、ＳｔａｃｋＧｕａｒｄで用いられる従来の手法では、スタックスマッシング攻撃を完全に防止することができなかった。
【００１１】
また、ＳｔａｃｋＧｕａｒｄでは、一度目のリターンで汚されたフレームポインタの影響を検出するために、二度目のリターンでは必ずｇｕａｒｄ＿ｖａｌｕｅの有効性を確認しなくてはならない。そのため、全ての関数において、ｇｕａｒｄ＿ｖａｌｕｅの有効性を確認するプログラムを発生させている。したがって、ｇｕａｒｄ＿ｖａｌｕｅの有効性を確認する処理のために、必ずある程度のオーバーヘッドが発生していた。
さらにまた、ＳｔａｃｋＧｕａｒｄにおいては、リターンアドレス領域とＰＦＰ領域との間にｇｕａｒｄ＿ｖａｌｕｅを挿入するため、スタックのフレーム構造を変更することとなる。このため、ＳｔａｃｋＧｕａｒｄを実装したプログラムに対してデバッグ支援を行うことができなかった。
【００１２】
仮想記憶のページを操作し、スタック上のリターンアドレス格納箇所を書き込み禁止にする従来技術においては、リターンアドレスのみを保護し、フレームポインタを保護していないため、ＳｔａｃｋＧｕａｒｄと同様のセキュリティホールが存在し、スタックスマッシング攻撃を完全に防止することができなかった。
また、スタックページへの書き込みを行うときにはスーパーバイザーモードに制御が移るため、実行オーバーヘッドが大きいという欠点があった。
【００１３】
リターンアドレス専用のスタックを別に作成し、関数の入口でリターンアドレスを専用スタックにコピーし、関数リターン処理で専用スタックから戻す従来技術においては、リターンアドレスへの直接的な攻撃が可能であった。すなわち、グローバル変数領域に作成された専用スタックは、その値の有効性を確認しないで元のスタックに戻すため、専用スタックからリターンアドレスを戻す操作への攻撃が直接リターンアドレスへの攻撃となってしまう。
また、同従来技術は、専用スタックの管理オーバーヘッドが大きいという欠点があった。
【００１４】
全ての配列アクセスに対して境界チェックを行う場合は、上述したようにバッファオーバーフローを原因とするあらゆる攻撃を防止することができるが、主にポインタを使用したプログラムではオーバーヘッドが非常に大きいという欠点があった。
【００１５】
本発明は以上のような技術的課題を解決するためになされたものであって、スタック上のバッファオーバーフローを原因とするスタックスマッシング攻撃を完全に防止することを目的とする。
また、スタックスマッシング攻撃の防止手段を実装したことによる実行オーバーヘッドを削減することを他の目的とする。
【００１６】
【課題を解決するための手段】
かかる目的のもと、本発明は、コンピュータシステムが使用するメモリ装置であって、このコンピュータシステムがプログラムを実行する際の関数呼び出し後におけるこのメモリ装置のメモリパターンとして、実行中の関数の呼び出し元へのリターンアドレスを格納する領域と、この実行中の関数の呼び出し元へのプレヴィアス・フレームポインタを格納する領域と、このリターンアドレスを格納する領域とこのプレヴィアス・フレームポインタを格納する領域との後方に位置し、ローカル変数を格納する領域とを備え、このローカル変数を格納する領域は、このローカル変数を格納する領域に配列が格納されている場合に、この配列よりも前に、実行中の関数のリターン処理において破壊されていないかどうかを確認する対象であるガード変数を格納したメモリパターンを有することを特徴としている。このような構成とすれば、リターンアドレスと共にプレヴィアス・フレームポインタをも保護することにより、スタックスマッシング攻撃を用いたシステムへの侵入を確実に阻止することができる。
さらに、ガード変数を用いたスタック保護処理の対象を、ローカル変数を格納する領域に配列が格納されている場合に限定することにより、システム全体のオーバーヘッドを低減させることができる。
【００１７】
ここで、メモリ装置のメモリパターンにおけるローカル変数を格納する領域は、このローカル変数を格納する領域に文字配列が格納されている場合に、この配列よりも前に、ガード変数を格納する構成とすることができる。すなわち、ローカル変数を格納する領域に、配列のうちの文字配列が格納されている場合にのみ、ガード変数を用いたスタック保護処理を実行する。このような構成とすれば、文字配列を持たない関数の他に整数配列のような文字配列以外の配列を持つ関数に対してもガード変数を用いたスタック保護処理を行わないため、システム全体のオーバーヘッドを更に低減させることができる。
スタックスマッシング攻撃の対象となる配列は、主に文字配列であるため、ガード変数を用いたスタック保護処理の対象を文字配列を持つ関数のみに限定しても、安全性が大幅に損なわれることはない。そこで、処理速度が重視されるシステムでは、このような構成とすることが好ましい。
【００１８】
また、ローカル変数を格納する領域に格納されるガード変数として、乱数を用いる構成とすることができる。このほか、ガード変数としては、攻撃者が知ることのできない任意の値を用いることができる。
【００１９】
さらに本発明においては、コンピュータシステムが使用するメモリ装置であって、このコンピュータシステムがプログラムを実行する際の関数呼び出し後におけるこのメモリ装置のメモリパターンとして、実行中の関数の呼び出し元へのリターンアドレスを格納する領域と、このリターンアドレスを格納する領域の後方に位置し、実行中の関数の呼び出し元へのプレヴィアス・フレームポインタを格納する領域と、このプレヴィアス・フレームポインタを格納する領域の後方に位置し、ローカル変数を格納する領域とを備え、このローカル変数を格納する領域に配列が格納されている場合に、このプレヴィアス・フレームポインタとこの配列との間に、実行中の関数のリターン処理において破壊されていないかどうかを確認する対象であるガード変数を格納したメモリパターンを有することを特徴としている。すなわち、ガード変数を格納する位置は、スタック上のプレヴィアス・フレームポインタと配列との間であれば、どこでも良い。
【００２０】
また、本発明は、コンピュータによるプログラムの実行の際にスタックスマッシング攻撃からプログラムカウンタを保護するスタック保護システムであって、ソース形式のプログラムを入力し、関数呼び出し後のスタックにおけるプレヴィアス・フレームポインタとローカル変数としてこのスタックに格納される配列との間にガード変数を格納する指令をこのソース形式のプログラムに付加するスタック保護指令作成部と、このスタック保護指令作成部によりガード変数を格納する指令を付加されたプログラムを実行し、このガード変数を格納する指令にしたがって、関数呼び出しの際にスタックにこのガード変数を格納すると共に、この関数のリターン処理においてこのガード変数の有効性を確認するスタック保護処理実行部とを備えることを特徴としている。このような構成とすれば、プログラムを実行する際に、リターンアドレスと共にプレヴィアス・フレームポインタをも保護することができ、スタックスマッシング攻撃を用いたシステムへの侵入を確実に阻止することができる点で優れている。
【００２１】
ここで、スタック保護処理実行部は、関数のリターン処理においてガード変数が破壊されていることを検出した場合に、プログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知する異常終了処理を行う構成とすることができる。このような構成とすれば、スタックスマッシング攻撃が行われた場合には、かかる関数の呼び出し元へ処理が戻る直前でプログラムの実行を中止するため、システムへの侵入を効果的に防止することができる点で好ましい。
【００２２】
また、スタック保護指令作成部は、コンパイラに実装され、このコンパイラが、ソース形式のプログラムとしてコンパイラ言語にて記述されたソースプログラムを入力し、このソースプログラムをオブジェクトプログラムに翻訳する際に、このオブジェクトプログラムに対して、ガード変数を格納する指令を付加する構成とすることができる。このような構成とすれば、オーバーフローを引き起こす変数よりもスタック上で上位アドレスにガード変数の宣言を配置すること、及び全ての関数の出口にプログラムを挿入することが容易となる点で好ましい。
【００２３】
さらに本発明においては、コンピュータによるプログラムの実行の際にスタックスマッシング攻撃からプログラムカウンタを保護するスタック保護システムであって、関数を実行する際にスタック上におけるプレヴィアス・フレームポインタとローカル変数としてスタックに格納される配列との間にガード変数を格納する指令が付加されたプログラムを入力して実行すると共に、このガード変数を格納する指令にしたがって、関数呼び出しの際にスタックに前記ガード変数を格納し、この関数のリターン処理においてこのガード変数の有効性を確認するプログラム実行手段と、このプログラム実行手段により、関数のリターン処理においてこのガード変数が破壊されていることが検出された場合に、プログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知する異常終了処理を行う異常終了実行手段とを備えることを特徴としている。このような構成とすれば、手作業を含むどのような手段でプログラムにガード変数を格納する指令を付加した場合であっても、そのようなプログラムを実行する際にスタック保護を実行できる点で好ましい。
【００２４】
また、本発明は、種々の演算処理を行うデータ処理装置と、このデータ処理装置が演算処理を行う際に用いるメモリ装置とを備えたコンピュータシステムであって、このデータ処理装置が演算処理を実行する際の関数呼び出し後におけるこのメモリ装置のメモリパターンは、実行中の関数の呼び出し元へのリターンアドレスを格納する領域と、実行中の関数の呼び出し元へのプレヴィアス・フレームポインタを格納する領域と、このリターンアドレスを格納する領域とこのプレヴィアス・フレームポインタを格納する領域との後方に位置し、ローカル変数を格納する領域とを備え、このローカル変数を格納する領域は、このローカル変数を格納する領域に配列が格納されている場合に、この配列よりも前に、実行中の関数のリターン処理において破壊されていないかどうかを確認する対象であるガード変数を格納したことを特徴としている。このような構成とすれば、リターンアドレスと共にプレヴィアス・フレームポインタをも保護することにより、スタックスマッシング攻撃を用いたシステムへの侵入を確実に阻止することができる。さらに、ガード変数を用いたスタック保護処理の対象を、ローカル変数を格納する領域に配列が格納されている場合に限定することにより、システム全体のオーバーヘッドを低減させることができる。
【００２５】
また、本発明は、種々の演算処理を行うデータ処理装置と、このデータ処理装置が演算処理を行う際に用いるメモリ装置とを備えたコンピュータシステムであって、このデータ処理装置が演算処理を実行する際の関数呼び出し後におけるこのメモリ装置のメモリパターンは、実行中の関数の呼び出し元へのリターンアドレスを格納する領域と、このリターンアドレスを格納する領域の後方に位置し、実行中の関数の呼び出し元へのプレヴィアス・フレームポインタを格納する領域と、このプレヴィアス・フレームポインタを格納する領域の後方に位置し、ローカル変数を格納する領域とを備え、このローカル変数を格納する領域に配列が格納されている場合に、このプレヴィアス・フレームポインタとこの配列との間に、実行中の関数のリターン処理において破壊されていないかどうかを確認する対象であるガード変数を格納したことを特徴としている。ガード変数を格納する位置は、スタック上のプレヴィアス・フレームポインタと配列との間であれば、どこでも良い。
【００２６】
さらにまた、本発明は、プログラム制御により種々の演算処理を行うコンピュータシステムであって、関数を実行する際にスタック上におけるプレヴィアス・フレームポインタとローカル変数としてスタックに格納される配列との間にガード変数を格納する指令が付加されたプログラムを読み込んで実行するデータ処理装置と、このデータ処理装置が演算処理を行う際に用いるメモリ装置とを備え、このデータ処理装置は、前記ガード変数を格納する指令が付加されたプログラムにおけるガード変数を格納する指令にしたがって、関数呼び出しの際に、メモリ装置上のスタックにこのガード変数を格納すると共に、この関数のリターン処理においてこのガード変数の有効性を確認することを特徴としている。このような構成とすれば、ガード変数を格納する指令が付加されたプログラムを、磁気ディスクや光ディスクなどの種々の記憶媒体に記録して提供したり、ネットワークを介して提供したりすることにより、このプログラムをインストールしたコンピュータシステムにおいて、スタック保護を実行できる点で好ましい。
【００２７】
ここで、データ処理装置は、関数のリターン処理においてガード変数が破壊されていることを検出した場合に、このプログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知する異常終了処理を行うことを特徴としている。このような構成とすれば、スタックスマッシング攻撃が行われた場合には、かかる関数の呼び出し元へ処理が戻る直前でプログラムの実行を中止するため、システムへの侵入を効果的に防止することができる点で好ましい。
【００２８】
また、本発明は、プログラム制御により種々の演算処理を行うコンピュータシステムであって、ソース形式のプログラムを入力し、関数呼び出し後のスタックにおけるプレヴィアス・フレームポインタとローカル変数としてこのスタックに格納される配列との間にガード変数を格納する指令をこのソース形式のプログラムに付加すると共に、このガード変数を格納する指令を付加されたプログラムを実行するデータ処理装置と、このデータ処理装置が演算処理を行う際に用いるメモリ装置とを備え、このデータ処理装置は、このガード変数を格納する指令を付加されたプログラムにおけるガード変数を格納する指令にしたがって、関数呼び出しの際に、このメモリ装置上のスタックにこのガード変数を格納すると共に、この関数のリターン処理においてこのガード変数の有効性を確認することを特徴としている。このような構成とすれば、任意のプログラムに対して、ガード変数を格納する指令を付加し、このプログラムを実行することによって、スタックスマッシング攻撃を用いたシステムへの侵入を確実に阻止することができる点で優れている。ここで、プログラムは、コンパイラ言語で記述されたものであっても、インタプリタ言語で記述されたものであってもかまわない。コンパイラ言語で記述されたプログラムである場合は、データ処理装置は、コンパイラとしての機能も併せて有することとなる。
【００２９】
ここで、データ処理装置は、関数のリターン処理においてガード変数が破壊されていることを検出した場合に、このプログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知する異常終了処理を行うことを特徴としている。このような構成とすれば、スタックスマッシング攻撃が行われた場合には、かかる関数の呼び出し元へ処理が戻る直前でプログラムの実行を中止するため、システムへの侵入を効果的に防止することができる点で好ましい。
【００３０】
また、本発明は、ソースプログラムを入力しオブジェクトプログラムに翻訳して出力するコンパイラであって、プログラムを翻訳する翻訳手段と、プログラムの翻訳の際に、サブルーチンごとに、このサブルーチンに含まれる関数が配列を持っているかどうかを調べ、配列を持っている場合に、このサブルーチンに対して、この関数を実行する際のスタックにおいてプレヴィアス・フレームポインタとローカル変数としてこのスタックに格納される配列との間にガード変数を格納すると共に、関数のリターン処理においてこのガード変数の有効性を確認する旨の指令を付加するスタック保護指令付加手段とを備えることを特徴としている。このような構成とすれば、ソースプログラムをコンパイルした時点で必要な指令をプログラムに付加することができる点で優れている。
【００３１】
さらにまた、本発明は、コンピュータによるプログラムの実行の際にスタックスマッシング攻撃からプログラムカウンタを保護するスタック保護方法であって、ソース形式のプログラムに対して、関数呼び出し後のスタックにおけるプレヴィアス・フレームポインタとローカル変数としてこのスタックに格納される配列との間にガード変数を格納する指令をこのソース形式のプログラムに付加するステップと、このガード変数を格納する指令を付加されたプログラムを実行すると共に、このガード変数を格納する指令にしたがって、関数呼び出しの際にスタックにこのガード変数を格納し、関数のリターン処理においてこのガード変数の有効性を確認するステップと、この関数のリターン処理においてこのガード変数が破壊されていることが検出された場合に、このプログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知するステップとを含むことを特徴としている。
【００３２】
同様にして、コンピュータによるプログラムの実行の際にスタックスマッシング攻撃からプログラムカウンタを保護するスタック保護方法であって、関数を実行する際にスタック上におけるプレヴィアス・フレームポインタとローカル変数としてスタックに格納される配列との間にガード変数を格納する指令が付加されたプログラムを実行すると共に、このガード変数を格納する指令にしたがって、関数呼び出しの際にスタックにこのガード変数を格納し、関数のリターン処理においてこのガード変数の有効性を確認するステップと、関数のリターン処理においてこのガード変数が破壊されていることが検出された場合に、このプログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知するステップとを含む構成とすることができる。このような構成とすれば、手作業を含むどのような手段でプログラムにガード変数を格納する指令を付加した場合であっても、そのようなプログラムを実行する際にスタック保護を実行できる点で好ましい。
【００３３】
また、本発明は、コンピュータに実行させるプログラムを当該コンピュータの入力手段が読取可能に記憶した記憶媒体において、このプログラムは、配列を持っている関数を実行する際のスタックにおいてプレヴィアス・フレームポインタとローカル変数としてこのスタックに格納される配列との間にガード変数を格納する処理と、関数のリターン処理においてこのガード変数の有効性を確認する処理と、関数のリターン処理においてこのガード変数が破壊されていることが検出された場合に、このプログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知する処理とをこのコンピュータに実行させることを特徴としている。このような構成とすれば、このプログラムを実行する全てのシステムにおいて、スタックスマッシング攻撃からプログラムカウンタを保護できる点で好ましい。
なお、このプログラムは、その種類において何ら制限はなく、コンパイラ言語であってもインタプリタ言語であっても良い。
【００３４】
さらにまた、本発明は、コンピュータに、配列を持っている関数を実行する際のスタックにおいてプレヴィアス・フレームポインタとローカル変数としてこのスタックに格納される配列との間にガード変数を格納する処理と、関数のリターン処理においてこのガード変数の有効性を確認する処理と、関数のリターン処理においてこのガード変数が破壊されていることが検出された場合に、このプログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知する処理とを実行させるプログラムを記憶する記憶手段と、この記憶手段からこのプログラムを読み出してこのプログラムを送信する送信手段とを備えたことを特徴としている。このような構成とすれば、このプログラム伝送装置からこのプログラムをダウンロードしてインストール可能なあらゆるシステムにおいて、スタックスマッシング攻撃からプログラムカウンタを保護できる。
【００３５】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいてこの発明を詳細に説明する。
まず、本発明の概要を説明する。本発明では、プログラムを実行する際のメモリパターン（記憶域の割当て）において、スタック上のプレヴィアス・フレームポインタ（Ｐｒｅｖｉｏｕｓ ｆｒａｍｅ ｐｏｉｎｔｅｒ：ＰＦＰ）とローカル変数領域における配列との間に、スタックスマッシング攻撃からプログラムカウンタを保護するための特別な値であるガード変数を挿入する。そして、関数リターン処理において、ガード変数の有効性を確認することにより、スタックスマッシング攻撃の有無を確認する。
スタックスマッシング攻撃においては、ローカル変数への代入操作を行い、境界チェックが不完全な場合に、そのローカル変数より上位のスタック領域を破壊する。したがって、プレヴィアス・フレームポインタと配列との間にガード変数を挿入されたスタックに対して、スタックスマッシング攻撃が行われると、関数の出口でガード変数が破壊されていることが検出される。この時点でプログラムの実行を止めることにより、当該関数の呼び出し元へのリターンアドレス及びプレヴィアス・フレームポインタを保護することができ、当該システムへの侵入を阻止することができる。
【００３６】
図１は、本実施の形態におけるスタック保護システムの全体構成を説明する図である。図１において、符号１１１はソース形式のプログラムである。符号１１２はスタック保護指令作成部であり、ソース形式のプログラム１１１における所定の箇所にガード変数を格納するための指令を作成してプログラムに付加する。符号１２１は、ガード変数を格納するための処理指令とガード変数の格納位置とを付加されたプログラムである。符号１３１はスタックであり、コンピュータのメモリ装置におけるメモリパターンを形成する。符号１３２はスタック保護処理実行部であり、プログラム１２１を実行すると共に、その際にプログラム１２１に付加されている処理指令及びガード変数の格納位置に基づいてスタックの保護処理を実行する。符号１３３は保護数値であり、ガード変数として用いられる値である。
【００３７】
図２は、コンピュータにおいて、本実施の形態によりスタックの保護処理が実行されている場合におけるメモリ装置のスタックの状態（メモリパターン）を示す図である。図２に示すように、スタックトップ（図では下側）から順に、ローカル変数領域２１０、プレヴィアス・フレームポインタ（ＰＦＰ）２２０、及び当該呼び出し元へのリターンアドレス（ＲＡ）２３０が積まれている。そして、ローカル変数領域２１０における配列２１１の前、すなわち、配列２１１とプレヴィアス・フレームポインタ（ＰＦＰ）２２０との間にガード変数（Ｇ）２１２が格納されている。ガード変数（Ｇ）２１２の位置は、配列２１１とプレヴィアス・フレームポインタ（ＰＦＰ）２２０との間であればよく、この位置に格納される他のローカル変数との前後関係は問わない。
【００３８】
図３は、図１に示したスタック保護システムにおけるスタック保護指令作成部１１２の処理を説明するフローチャートである。スタック保護指令作成部１１２は、ソース形式のプログラム１１１のサブルーチンごとに、図３に示す処理を実行する。図３を参照すると、スタック保護指令作成部１１２は、まず着目中のサブルーチンにおいて、ローカル変数として配列が使用されているかどうかを確認する（ステップ３０１）。
そして、配列が使用されている場合は、ガード変数（Ｇ）の格納位置を決定する（ステップ３０２）。ここで、ガード変数（Ｇ）の格納位置は、上述したように、プレヴィアス・フレームポインタと配列との間の任意の位置である。次に、当該サブルーチンを実行する際に、スタックにおける、ステップ３０２で決定された当該ガード変数（Ｇ）の格納位置にガード変数（Ｇ）を格納する旨の処理指令を生成する（ステップ３０３）。
以上のようにして、ガード変数を格納するための処理指令とガード変数の格納位置とを付加されたプログラム１２１が出力される。
【００３９】
プログラム１２１には、実際には、ガード変数を挿入すべきサブルーチン（関数）ごとに、ガード変数の宣言、関数の入口におけるガード変数の値の設定、関数の出口におけるガード変数の値の確認及び異常終了を実行するための命令が埋め込まれることとなる。このプログラム１２１の具体的な構成例は後述する。
【００４０】
図４は、スタック保護処理実行部１３２の処理を説明するフローチャートである。スタック保護処理実行部１３２は、スタック保護指令作成部１１２によりガード変数を格納するための処理指令とガード変数の格納位置とを付加されたプログラム１２１のサブルーチンごとに、図４に示す処理を実行する。図４を参照すると、まずプログラム１２１の着目中のサブルーチンにおいて、スタック保護指令作成部１１２により付加された処理指令があるかどうかを調べる（ステップ４０１）。
そして、処理指令がある場合は、当該プログラム１２１に処理指令と共に付加されているガード変数（Ｇ）格納位置に対応するスタック１３１上の位置にガード変数（Ｇ）の格納領域を生成する（ステップ４０２）。上述したように、ガード変数（Ｇ）の格納領域は、スタック１３１上のローカル変数領域であって、配列よりも前の位置に生成される。
【００４１】
次に、ステップ４０２で生成されたガード変数（Ｇ）の格納領域に、保護数値１３３を格納する（ステップ４０３）。これにより、スタック１３１は、図２に示した状態となる。ガード変数（Ｇ）として格納される保護数値１３３の内容は、特に制約はないが、攻撃者が推定できない値や攻撃によって格納することのできない値とする。そのような値の例として乱数を利用することができる。
【００４２】
次に、当該サブルーチンの処理（関数）を実行する（ステップ４０４）。そして、関数の出口でガード変数（Ｇ）として格納した値が保持されているかどうかを確認する（ステップ４０５）。ガード変数（Ｇ）の値が保持されていれば、通常通り終了する。また、ガード変数（Ｇ）の値が保持されていない場合は、スタックスマッシング攻撃が行われたことを意味するので、攻撃があったことを示すメッセージ及びエラーログを出力してプログラムを終了する（ステップ４０６）。
以上のようにして、スタックスマッシング攻撃があれば、リターン処理の直前で検出でき、コンピュータシステムへの侵入を防止できることとなる。
【００４３】
本実施の形態のスタック保護システムは、結果的にプログラムの実行段階において、メモリパターンとして、図２に示したように、スタック上のプレヴィアス・フレームポインタと配列との間にガード変数を配置できれば良い。したがって、本実施の形態によるスタック保護システムを実現するにあたり、プログラミング言語の種類やシステムの形態に応じて、種々の態様を採ることができる。例えば、プログラミング言語がコンパイラ言語である場合は、スタック保護指令作成部１１２の機能をコンパイラに実装することができる。この場合、スタック保護指令作成部１１２により処理指令及びガード変数（Ｇ）の格納位置を付加されたプログラム１２１は、実行形式のプログラムとなる。コンパイラのコード生成時にガード変数を挿入するためのプログラムを埋め込むこととすれば、オーバーフローを引き起こす変数よりもスタック上で上位アドレスにガード変数の宣言を配置すること、及び全ての関数の出口にプログラムを挿入することが容易となる点で好ましい。
【００４４】
これに対し、プログラミング言語がインタプリタ言語である場合は、スタック保護指令作成部１１２により処理指令及びガード変数（Ｇ）の格納位置を付加されたプログラム１２１の段階では、未だソース形式のプログラムである。
また、プログラミング言語がコンパイラ言語である場合であっても、コンパイラの前段にスタック保護指令作成部１１２を構成する処理装置を置き、ソースプログラムの段階でガード変数を挿入するためのプログラムを埋め込むようにしても良い。図１０に示したＣ言語のソースプログラムに対してガード変数を挿入するためのプログラムを埋め込む例を図５及び図６を参照して説明する。
この場合、スタック保護指令作成部１１２は、図５に示す３つのプログラムを、図１０のプログラムの変数宣言部、関数の入口、関数の出口にそれぞれ挿入する。各プログラムが挿入された状態が図６に示すプログラムである。図６を参照すると、変数宣言部である符号６０１の位置、関数の入口である符号６０２の位置、関数の出口である符号６０３の位置に、それぞれ図５に示した３つのプログラムが挿入されている。
【００４５】
このように、スタック保護システムを実現するには、プログラミング言語の種類やシステムの形態に応じて、種々の態様を採ることが可能である。上記の他にも、ソース形式のプログラムを作成する段階で、所望の関数に対して、手作業により図５に示したようなプログラムを書き込むことも可能である。この場合、スタック保護指令作成部１１２の処理が手作業にて行われることに相当する。したがって、作成されたプログラムは最初からプログラム１２１の状態であり、スタック保護システムとしては、スタック保護処理実行部１３２による処理だけが実行されることとなる。
【００４６】
図７は、本実施の形態のスタック保護システムを適用したコンピュータシステムの構成例を説明する図である。図７に示すコンピュータシステム７００は、データ処理を行うデータ処理装置７１０と、データ処理装置７１０による処理の際に用いられるメモリ装置７２０と、データ処理装置７１０を制御する制御プログラム７３１を格納した記憶装置７３０とを備える。
ＣＰＵにて実現されるデータ処理装置７１０は、制御プログラム７３１の制御の下、スタック保護処理実行部１３２の機能を実現する。メモリ装置７２０は、スタック保護処理実行部１３２による関数の実行において、スタック７２１上に、図２に示したガード変数を含むメモリパターンを形成する。さらに、データ処理装置７１０のスタック保護処理実行部１３２は、メモリ装置７２０のスタック７２１上に図２に示したメモリパターンを形成する際に、ガード変数の値として、記憶装置７３０から読み出した保護数値１３３を挿入する。
なお、コンピュータシステム７００において、コンパイラ言語が実行される場合は、制御プログラム７３１は、図１に示したプログラム１２１に相当する実行形式のプログラムとなる。また、記憶装置７３０に格納された制御プログラム７３１を、ガード変数を格納するための処理指令とガード変数の格納位置とを付加されたソース形式のプログラムとすることもできる。この場合、データ処理装置７１０は、コンパイラの機能を併せて備えることとなる。さらに、制御プログラム７３１を、ガード変数を格納するための処理指令とガード変数の格納位置とを付加する前のソース形式のプログラムとすることもできる。この場合、制御プログラム７３１は、図１に示したソース形式のプログラム１１１に相当し、データ処理装置７１０は、スタック保護指令作成部１１２の機能を更に備えることとなる。さらにまた、図７においては、メモリ装置７２０と記憶装置７３０とを別個の構成要素として記載したが、物理的には単一の記憶モジュールにて構成することができる。
【００４７】
次に、本実施の形態におけるオーバーフローの低減について説明する。
変数の型宣言とその参照とが正しく対応しているプログラムにおいては、バッファオーバーフローが発生する変数は、サイズ情報を持たない配列である。Ｃ言語などで使用されるこのような配列は、サイズ情報がないため、コンパイラの型チェックだけではバッファオーバーフローを防ぐことができない。一方、配列以外の変数では、プログラミング作法として型変換に注意を払えば、バッファオーバーフローを防ぐことが可能である。
したがって、上述したように本実施の形態では、図２に示したように、スタックのローカル変数領域における配列とプレヴィアス・フレームポインタとの間にガード変数を格納し、ローカル変数として配列を持たない場合はガード変数を格納しないこととした。これにより、システム全体のオーバーヘッドの低減を図ることができる。
【００４８】
ここで、変数の型宣言とその参照とが正しく対応しているプログラムにおいて、テスト領域に配列を持っていない関数（ＡＦ関数と称す）では、ガード変数を用いたバッファオーバーフローのテストを行う必要がないことを証明する。
図８は、スタックにおけるテスト領域を説明する図である。スタック上のガード変数を用いてバッファオーバーフローのテストを行う領域は、当該ガード変数とそれよりも下位に現れるガード変数との間の領域、すなわち、図８の斜線を付した領域である。この領域を関数のテスト領域８０１と呼ぶこととする。証明は次の２つのステップで行う。
１．ＡＦ関数のテスト領域８０１が破壊されるのは、それ以降に呼ばれる関数のテスト領域８０１がバッファオーバーフローを起こした場合であり、またその場合だけであることを示す。
２．ＡＦ関数のテスト領域８０１が破壊された場合は、ＡＦ関数に実行制御が戻らないことを示す。
【００４９】
まず、第１のステップについて説明する。ＡＦ関数のテスト領域８０１には配列は存在しない。したがって、テスト領域８０１が破壊されたとしても、当該テスト領域がバッファオーバーフローの発生源ではない。したがって、テスト領域８０１の破壊の原因は、スタック上の当該関数フレームの上に置かれたテスト領域８０１となる。すなわち、ＡＦ関数から呼び出された関数の中でバッファオーバーフローが生じ、スタックの上位アドレスの向きに破壊して、ＡＦ関数のテスト領域を壊したものである。
【００５０】
次に、第２のステップについて説明する。第１のステップにより、ＡＦ関数のテスト領域８０１の破壊原因は、それ以降に呼ばれる他の関数にある。また上述したように、変数の型宣言とその参照とが正しく対応しているプログラムにおいては、バッファオーバーフローが発生する変数は配列であるから、ＡＦ関数におけるテスト領域８０１の破壊の原因となった領域は、配列である。配列を定義した関数では、ガード変数を用いたバッファオーバーフローのテストが実行されている。そして、テスト領域８０１を破壊し、かつリターンアドレスを操作するような攻撃があった場合は、必ずガード変数が破壊される。そのため、当該関数のリターン処理でプログラムは停止する。したがって、ＡＦ関数まで実行制御が戻ることはない。
【００５１】
以上で、テスト領域８０１に配列を持っていないＡＦ関数では、ガード変数を用いたバッファオーバーフローのテストを行う必要がないことが証明された。
なお、本実施の形態では、配列一般に対してガード変数を用いたスタック保護を行うこととして説明したが、特に文字配列のみを対象としてガード変数を用いたスタック保護を行うこととしても良い。これは、スタックスマッシング攻撃の対象となる配列が主に文字配列だからである。さらにその理由は、文字配列が、プログラム外部の情報表現に使用すること、データサイズを確認せずに処理できるように終端記号を持つ表現であること、といった特徴を持つことにある。
したがって、ガード変数を用いたスタック保護を行う関数を、ローカル変数として文字配列を持つものに限定し、文字配列を持たないもの及び整数配列のような文字配列以外の配列を持つものについては、ガード変数を格納しないことにより、システム全体のオーバーヘッドを更に低減させることができる。
【００５２】
以上のように、本実施の形態では、関数のリターン処理において、スタックのプレヴィアス・フレームポインタと配列との間に格納されたガード変数の有効性を確認する。これにより、スタック上のバッファオーバーフローを原因とするスタックスマッシング攻撃に関しては、ネットワーク経由での攻撃及びローカルユーザからの攻撃のいずれに対しても防止することができる。
【００５３】
また、本実施の形態では、ローカル変数として配列を持つ関数のみを対象としてガード変数を用いたスタック保護を実行するため、従来技術において説明したように、全ての関数に対してスタック保護のための処理を実行する場合と比べてオーバーヘッドの削減を図ることができる。特にリターンアドレスの格納箇所を書き込み禁止にする場合や、リターンアドレス専用のスタックを用意する場合と比べると、大幅なオーバーヘッドの削減を実現できる。
さらに、ローカル変数として文字配列を持つ関数のみを対象としてガード変数を用いたスタック保護を行うこととすれば、さらなるオーバーヘッドの削減を図ることができる。
【００５４】
なお、本実施の形態では、上述したようにガード変数をローカル変数領域に格納するため、スタックのフレーム構造を変更することがない。したがって、プログラムに対するデバッガによるデバッグ支援処理を行うことができなくなると行った不都合もない。
【００５５】
【発明の効果】
以上説明したように、本発明によれば、スタック上のバッファオーバーフローを原因とするスタックスマッシング攻撃を完全に防止することができる。
また、スタックスマッシング攻撃の防止手段を実装したことによる実行オーバーヘッドを削減することができる。
【図面の簡単な説明】
【図１】本実施の形態におけるスタック保護システムの全体構成を説明するための図である。
【図２】本実施の形態によりスタックの保護処理が実行されている場合のスタックの状態（メモリパターン）を示す図である。
【図３】本実施の形態におけるスタック保護指令作成部の処理を説明するフローチャートである。
【図４】本実施の形態におけるスタック保護処理実行部の処理を説明するフローチャートである。
【図５】本実施の形態においてスタック保護の対象とすべきプログラムに挿入する、スタック保護を実行するためのプログラムの例を示す図である。
【図６】図１０のプログラムに対して図５のプログラムを挿入した状態を示す図である。
【図７】本実施の形態のスタック保護システムを適用したコンピュータシステムの構成例を説明する図である。
【図８】スタックにおけるテスト領域を説明する図である。
【図９】Ｃ言語における関数呼び出し後のスタック状態を説明する図である。
【図１０】Ｃ言語で記述されたプログラムの例を示す図である。
【図１１】図１０のプログラムに対してスタックスマッシング攻撃が行われた場合のスタックの状態を説明する図である。
【符号の説明】
１１１…ソース形式のプログラム、１１２…スタック保護指令作成部、１２１…プログラム、１３１…スタック、１３２…スタック保護処理実行部、１３３…保護数値、７００…コンピュータシステム、７１０…データ処理装置、７２０…メモリ装置、７２１…スタック、７３０…記憶装置、７３１…制御プログラム、８０１…テスト領域
Claims (12)
- コンピュータによるプログラムの実行の際にスタックスマッシング攻撃からプログラムカウンタを保護するスタック保護システムであって、
ソース形式のプログラムを入力し、関数呼び出し後のスタックにおけるプレヴィアス・フレームポインタとローカル変数として当該スタックに格納される配列との間にガード変数を格納する指令を当該ソース形式のプログラムに付加するスタック保護指令作成部と、
前記スタック保護指令作成部により前記ガード変数を格納する指令を付加されたプログラムを実行し、当該ガード変数を格納する指令にしたがって、関数呼び出しの際にスタックに当該ガード変数を格納すると共に、当該関数のリターン処理において当該ガード変数の有効性を確認するスタック保護処理実行部とを備えることを特徴とするスタック保護システム。 - 前記スタック保護処理実行部は、
前記関数のリターン処理において前記ガード変数が破壊されていることを検出した場合に、前記プログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知する異常終了処理を行うことを特徴とする請求項１に記載のスタック保護システム。 - 前記スタック保護指令作成部は、コンパイラに実装され、
前記コンパイラが、前記ソース形式のプログラムとしてコンパイラ言語にて記述されたソースプログラムを入力し、当該ソースプログラムをオブジェクトプログラムに翻訳する際に、当該オブジェクトプログラムに対して、前記ガード変数を格納する指令を付加することを特徴とする請求項１に記載のスタック保護システム。 - コンピュータによるプログラムの実行の際にスタックスマッシング攻撃からプログラムカウンタを保護するスタック保護システムであって、
関数を実行する際にスタック上におけるプレヴィアス・フレームポインタとローカル変数としてスタックに格納される配列との間にガード変数を格納する指令が付加されたプログラムを入力して実行すると共に、当該ガード変数を格納する指令にしたがって、関数呼び出しの際にスタックに前記ガード変数を格納し、当該関数のリターン処理において当該ガード変数の有効性を確認するプログラム実行手段と、
前記プログラム実行手段により、前記関数のリターン処理において前記ガード変数が破壊されていることが検出された場合に、前記プログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知する異常終了処理を行う異常終了実行手段とを備えることを特徴とするスタック保護システム。 - プログラム制御により種々の演算処理を行うコンピュータシステムであって、
関数を実行する際にスタック上におけるプレヴィアス・フレームポインタとローカル変数としてスタックに格納される配列との間にガード変数を格納する指令が付加されたプログラムを読み込んで実行するデータ処理装置と、
前記データ処理装置が演算処理を行う際に用いるメモリ装置とを備え、
前記データ処理装置は、前記ガード変数を格納する指令が付加されたプログラムにおける前記ガード変数を格納する指令にしたがって、関数呼び出しの際に、前記メモリ装置上のスタックに当該ガード変数を格納すると共に、当該関数のリターン処理において当該ガード変数の有効性を確認することを特徴とするコンピュータシステム。 - 前記データ処理装置は、
前記関数のリターン処理において前記ガード変数が破壊されていることを検出した場合に、前記プログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知する異常終了処理を行うことを特徴とする請求項５に記載のコンピュータシステム。 - プログラム制御により種々の演算処理を行うコンピュータシステムであって、
ソース形式のプログラムを入力し、関数呼び出し後のスタックにおけるプレヴィアス・フレームポインタとローカル変数として当該スタックに格納される配列との間にガード変数を格納する指令を当該ソース形式のプログラムに付加すると共に、当該ガード変数を格納する指令を付加されたプログラムを実行するデータ処理装置と、
前記データ処理装置が演算処理を行う際に用いるメモリ装置とを備え、
前記データ処理装置は、前記ガード変数を格納する指令を付加されたプログラムにおける前記ガード変数を格納する指令にしたがって、関数呼び出しの際に、前記メモリ装置上のスタックに当該ガード変数を格納すると共に、当該関数のリターン処理において当該ガード変数の有効性を確認することを特徴とするコンピュータシステム。 - 前記データ処理装置は、
前記関数のリターン処理において前記ガード変数が破壊されていることを検出した場合に、前記プログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知する異常終了処理を行うことを特徴とする請求項７に記載のコンピュータシステム。 - ソースプログラムを入力しオブジェクトプログラムに翻訳して出力するコンパイラであって、
プログラムを翻訳する翻訳手段と、
プログラムの翻訳の際に、サブルーチンごとに、当該サブルーチンに含まれる関数が配列を持っているかどうかを調べ、配列を持っている場合に、当該サブルーチンに対して、当該関数を実行する際のスタックにおいてプレヴィアス・フレームポインタとローカル変数として当該スタックに格納される当該配列との間にガード変数を格納すると共に、関数のリターン処理において当該ガード変数の有効性を確認する旨の指令を付加するスタック保護指令付加手段とを備えることを特徴とするコンパイラ。 - コンピュータによるプログラムの実行の際にスタックスマッシング攻撃からプログラムカウンタを保護するスタック保護方法であって、
ソース形式のプログラムに対して、関数呼び出し後のスタックにおけるプレヴィアス・フレームポインタとローカル変数として当該スタックに格納される配列との間にガード変数を格納する指令を当該ソース形式のプログラムに付加するステップと、
前記ガード変数を格納する指令を付加されたプログラムを実行すると共に、当該ガード変数を格納する指令にしたがって、関数呼び出しの際にスタックに当該ガード変数を格納し、関数のリターン処理において当該ガード変数の有効性を確認するステップと、
前記関数のリターン処理において前記ガード変数が破壊されていることが検出された場合に、前記プログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知するステップとを含むことを特徴とするスタック保護方法。 - コンピュータによるプログラムの実行の際にスタックスマッシング攻撃からプログラムカウンタを保護するスタック保護方法であって、
関数を実行する際にスタック上におけるプレヴィアス・フレームポインタとローカル変数としてスタックに格納される配列との間にガード変数を格納する指令が付加されたプログラムを実行すると共に、当該ガード変数を格納する指令にしたがって、関数呼び出しの際にスタックに当該ガード変数を格納し、関数のリターン処理において当該ガード変数の有効性を確認するステップと、
前記関数のリターン処理において前記ガード変数が破壊されていることが検出された場合に、前記プログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知するステップとを含むことを特徴とするスタック保護方法。 - コンピュータに実行させるプログラムを当該コンピュータの入力手段が読取可能に記憶した記憶媒体において、
前記プログラムは、
配列を持っている関数を実行する際のスタックにおいてプレヴィアス・フレームポインタとローカル変数として当該スタックに格納される当該配列との間にガード変数を格納する処理と、
前記関数のリターン処理において前記ガード変数の有効性を確認する処理と、
前記関数のリターン処理において前記ガード変数が破壊されていることが検出された場合に、前記プログラムの実行を中止し、スタックスマッシング攻撃があったことをユーザに通知する処理とを前記コンピュータに実行させることを特徴とする記憶媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000028358A JP3552627B2 (ja) | 2000-02-04 | 2000-02-04 | スタック保護システム、コンピュータシステム、コンパイラ、スタック保護方法および記憶媒体 |
| US09/772,373 US6941473B2 (en) | 2000-02-04 | 2001-01-30 | Memory device, stack protection system, computer system, compiler, stack protection method, storage medium and program transmission apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000028358A JP3552627B2 (ja) | 2000-02-04 | 2000-02-04 | スタック保護システム、コンピュータシステム、コンパイラ、スタック保護方法および記憶媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001216161A JP2001216161A (ja) | 2001-08-10 |
| JP3552627B2 true JP3552627B2 (ja) | 2004-08-11 |
Family
ID=18553773
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000028358A Expired - Fee Related JP3552627B2 (ja) | 2000-02-04 | 2000-02-04 | スタック保護システム、コンピュータシステム、コンパイラ、スタック保護方法および記憶媒体 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6941473B2 (ja) |
| JP (1) | JP3552627B2 (ja) |
Families Citing this family (77)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7380245B1 (en) * | 1998-11-23 | 2008-05-27 | Samsung Electronics Co., Ltd. | Technique for detecting corruption associated with a stack in a storage device |
| US7284274B1 (en) * | 2001-01-18 | 2007-10-16 | Cigital, Inc. | System and method for identifying and eliminating vulnerabilities in computer software applications |
| DE60220214T2 (de) * | 2001-06-29 | 2008-01-24 | Stonesoft Corp. | Methode und System zum Entdecken von Eindringlingen |
| US7853803B2 (en) | 2001-09-28 | 2010-12-14 | Verizon Corporate Services Group Inc. | System and method for thwarting buffer overflow attacks using encrypted process pointers |
| JP2003140972A (ja) * | 2001-11-08 | 2003-05-16 | Nec Corp | プログラム実行装置及びプログラム実行方法並びにそれを用いた携帯端末及び情報提供システム |
| KR100560166B1 (ko) * | 2001-12-05 | 2006-03-13 | 한국전자통신연구원 | 실시간 버퍼 오버플로우 해킹 탐지 방법 |
| CA2372034A1 (en) * | 2002-02-14 | 2003-08-14 | Cloakware Corporation | Foiling buffer-overflow and alien-code attacks by encoding |
| FR2836569B1 (fr) * | 2002-02-28 | 2005-02-25 | Gemplus Card Int | Espace memoire pour donnees d'application telechargees dans une carte a puce |
| US20030204745A1 (en) * | 2002-04-29 | 2003-10-30 | International Business Machines Corporation | Method and system for protecting a processing system from a buffer overflow attack |
| US7155741B2 (en) * | 2002-05-06 | 2006-12-26 | Symantec Corporation | Alteration of module load locations |
| US7418729B2 (en) * | 2002-07-19 | 2008-08-26 | Symantec Corporation | Heuristic detection of malicious computer code by page tracking |
| US20040168078A1 (en) * | 2002-12-04 | 2004-08-26 | Brodley Carla E. | Apparatus, system and method for protecting function return address |
| US7660985B2 (en) * | 2003-04-30 | 2010-02-09 | At&T Corp. | Program security through stack segregation |
| EP1662379A4 (en) * | 2003-09-04 | 2008-12-03 | Science Park Corp | FALSE COORDINATE PROCEDURE AND PREVENTION PROGRAM |
| US7587615B2 (en) * | 2003-09-12 | 2009-09-08 | International Business Machines Corporation | Utilizing hardware transactional approach to execute code after initially utilizing software locking by employing pseudo-transactions |
| EP1526457B1 (en) * | 2003-10-22 | 2013-03-13 | Sony Deutschland GmbH | Context-aware automatic service discovery and execution engine in mobile ad-hoc networks |
| US7716495B2 (en) * | 2003-12-31 | 2010-05-11 | Microsoft Corporation | Protection against runtime function attacks |
| US7434020B2 (en) * | 2003-12-31 | 2008-10-07 | Microsoft Corporation | Overwrite detection diagnostic for memory heap |
| KR100586500B1 (ko) * | 2004-03-18 | 2006-06-07 | 학교법인고려중앙학원 | 버퍼 오버플로우 공격들을 감지하고 복구하는 방법 및 그장치 |
| JP4643201B2 (ja) * | 2004-08-12 | 2011-03-02 | 日本電信電話株式会社 | バッファオーバーフロー脆弱性分析方法、データ処理装置、分析情報提供装置、分析情報抽出処理用プログラムおよび分析情報提供処理用プログラム |
| US7467272B2 (en) * | 2004-12-16 | 2008-12-16 | International Business Machines Corporation | Write protection of subroutine return addresses |
| US7774783B2 (en) * | 2004-12-23 | 2010-08-10 | Microsoft Corporation | Method and apparatus for detecting deadlocks |
| JP2006185347A (ja) * | 2004-12-28 | 2006-07-13 | Fujitsu Ltd | 情報処理装置及び情報処理方法 |
| US20070083770A1 (en) * | 2005-09-17 | 2007-04-12 | Technology Group Northwest Inc. | System and method for foiling code-injection attacks in a computing device |
| US7739740B1 (en) | 2005-09-22 | 2010-06-15 | Symantec Corporation | Detecting polymorphic threats |
| US8510596B1 (en) * | 2006-02-09 | 2013-08-13 | Virsec Systems, Inc. | System and methods for run time detection and correction of memory corruption |
| US8528093B1 (en) * | 2006-04-12 | 2013-09-03 | Hewlett-Packard Development Company, L.P. | Apparatus and method for performing dynamic security testing using static analysis data |
| US7581089B1 (en) | 2006-04-20 | 2009-08-25 | The United States Of America As Represented By The Director Of The National Security Agency | Method of protecting a computer stack |
| US7818799B2 (en) * | 2006-05-30 | 2010-10-19 | Microsoft Corporation | Tamper response mechanism |
| US8364910B2 (en) * | 2007-03-08 | 2013-01-29 | Daniel Shawcross Wilkerson | Hard object: hardware protection for software objects |
| US8806439B1 (en) | 2007-04-30 | 2014-08-12 | AT & T Intellectual Property II, LP | System and method for program stack security |
| US7856573B2 (en) * | 2007-08-31 | 2010-12-21 | International Business Machines Corporation | WPAR halted attack introspection stack execution detection |
| US20090187748A1 (en) * | 2008-01-22 | 2009-07-23 | Scott Krig | Method and system for detecting stack alteration |
| US8239836B1 (en) * | 2008-03-07 | 2012-08-07 | The Regents Of The University Of California | Multi-variant parallel program execution to detect malicious code injection |
| US8099636B2 (en) * | 2008-07-15 | 2012-01-17 | Caterpillar Inc. | System and method for protecting memory stacks using a debug unit |
| JP5039728B2 (ja) * | 2009-02-24 | 2012-10-03 | 三菱重工業株式会社 | コンピュータメモリにおけるスタック領域のデータの保護方法 |
| US9934166B2 (en) | 2010-12-10 | 2018-04-03 | Daniel Shawcross Wilkerson | Hard object: constraining control flow and providing lightweight kernel crossings |
| FR2977694A1 (fr) * | 2011-07-08 | 2013-01-11 | St Microelectronics Rousset | Microprocesseur protege contre un debordement de pile |
| US8990546B2 (en) | 2011-10-31 | 2015-03-24 | Freescale Semiconductor, Inc. | Data processing system with safe call and return |
| CN103294517B (zh) * | 2012-02-22 | 2018-05-11 | 国际商业机器公司 | 堆栈溢出保护装置、堆栈保护方法、相关编译器和计算装置 |
| US9256730B2 (en) * | 2012-09-07 | 2016-02-09 | Crowdstrike, Inc. | Threat detection for return oriented programming |
| US9177147B2 (en) | 2012-09-28 | 2015-11-03 | Intel Corporation | Protection against return oriented programming attacks |
| US9223979B2 (en) * | 2012-10-31 | 2015-12-29 | Intel Corporation | Detection of return oriented programming attacks |
| CA2809516C (en) | 2013-03-13 | 2016-11-08 | Khalid Nawaf Alharbi | Preventing stack buffer overflow attacks |
| US9569612B2 (en) | 2013-03-14 | 2017-02-14 | Daniel Shawcross Wilkerson | Hard object: lightweight hardware enforcement of encapsulation, unforgeability, and transactionality |
| US10445168B2 (en) | 2013-06-18 | 2019-10-15 | Nxp Usa, Inc. | Device and method for executing a program, and method for storing a program |
| WO2014203030A1 (en) | 2013-06-18 | 2014-12-24 | Freescale Semiconductor, Inc. | Detection of data corruption in a data processing device |
| US9223974B2 (en) * | 2013-07-09 | 2015-12-29 | Globalfoundries Inc. | Anti-viral compiler |
| EP3044719B1 (en) | 2013-09-12 | 2019-08-28 | Virsec Systems Inc. | Automated runtime detection of malware |
| US9703948B2 (en) * | 2014-03-28 | 2017-07-11 | Intel Corporation | Return-target restrictive return from procedure instructions, processors, methods, and systems |
| CA2953793C (en) | 2014-06-24 | 2021-10-19 | Virsec Systems, Inc. | System and methods for automated detection of input and output validation and resource management vulnerability |
| AU2015279920B2 (en) | 2014-06-24 | 2018-03-29 | Virsec Systems, Inc. | Automated root cause analysis of single or N-TIERED applications |
| US9977897B2 (en) * | 2014-07-16 | 2018-05-22 | Leviathan Security Group, Inc. | System and method for detecting stack pivot programming exploit |
| US20160028767A1 (en) * | 2014-07-25 | 2016-01-28 | Jose Ismael Ripoll | Method for Preventing Information Leaks on the Stack Smashing Protector Technique |
| EP2996034B1 (en) * | 2014-09-11 | 2018-08-15 | Nxp B.V. | Execution flow protection in microcontrollers |
| CN104536722B (zh) * | 2014-12-23 | 2018-02-02 | 大唐移动通信设备有限公司 | 基于业务处理流程的栈空间优化方法和系统 |
| US9569613B2 (en) * | 2014-12-23 | 2017-02-14 | Intel Corporation | Techniques for enforcing control flow integrity using binary translation |
| US9767292B2 (en) | 2015-10-11 | 2017-09-19 | Unexploitable Holdings Llc | Systems and methods to identify security exploits by generating a type based self-assembling indirect control flow graph |
| US9576128B1 (en) | 2016-01-06 | 2017-02-21 | International Business Machines Corporation | Interlinking routines with differing protections using stack indicators |
| US9495237B1 (en) | 2016-01-06 | 2016-11-15 | International Business Machines Corporation | Detection of corruption of call stacks |
| US9582274B1 (en) | 2016-01-06 | 2017-02-28 | International Business Machines Corporation | Architected store and verify guard word instructions |
| US10120745B2 (en) * | 2016-01-06 | 2018-11-06 | International Business Machines Corporation | Providing instructions to protect stack return addresses in a hardware managed stack architecture |
| US9514301B1 (en) | 2016-01-06 | 2016-12-06 | International Business Machines Corporation | Interlinking modules with differing protections using stack indicators |
| US10228992B2 (en) | 2016-01-06 | 2019-03-12 | International Business Machines Corporation | Providing instructions to facilitate detection of corrupt stacks |
| US9606855B1 (en) | 2016-01-06 | 2017-03-28 | International Business Machines Corporation | Caller protected stack return address in a hardware managed stack architecture |
| US9904485B2 (en) * | 2016-03-31 | 2018-02-27 | Intel Corporation | Secure memory controller |
| KR102419574B1 (ko) | 2016-06-16 | 2022-07-11 | 버섹 시스템즈, 인코포레이션 | 컴퓨터 애플리케이션에서 메모리 손상을 교정하기 위한 시스템 및 방법 |
| US10437990B2 (en) | 2016-09-30 | 2019-10-08 | Mcafee, Llc | Detection of return oriented programming attacks in a processor |
| US10423778B2 (en) * | 2016-12-29 | 2019-09-24 | Intel Corporation | Turing completeness disabling |
| US10579377B2 (en) | 2017-01-19 | 2020-03-03 | International Business Machines Corporation | Guarded storage event handling during transactional execution |
| US10452288B2 (en) * | 2017-01-19 | 2019-10-22 | International Business Machines Corporation | Identifying processor attributes based on detecting a guarded storage event |
| JP6996215B2 (ja) * | 2017-07-03 | 2022-01-17 | 株式会社デンソー | プログラム生成方法および電子制御装置 |
| US11496506B2 (en) * | 2017-07-03 | 2022-11-08 | Denso Corporation | Program generation method and electronic control unit for changing importance of functions based on detected operation state in a vehicle |
| JP6905190B2 (ja) | 2017-09-01 | 2021-07-21 | 富士通株式会社 | 情報処理装置およびスタック破壊検出プログラム |
| US11176060B2 (en) * | 2018-10-29 | 2021-11-16 | Sternum Ltd. | Dynamic memory protection |
| JP7334794B2 (ja) * | 2019-11-15 | 2023-08-29 | 日本電気株式会社 | 分析システム、方法およびプログラム |
| KR20220095986A (ko) * | 2020-12-30 | 2022-07-07 | 한국전자통신연구원 | 임베디드 프로세서의 소스 코드의 컴파일링 방법 및 컴파일러 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5949973A (en) * | 1997-07-25 | 1999-09-07 | Memco Software, Ltd. | Method of relocating the stack in a computer system for preventing overrate by an exploit program |
-
2000
- 2000-02-04 JP JP2000028358A patent/JP3552627B2/ja not_active Expired - Fee Related
-
2001
- 2001-01-30 US US09/772,373 patent/US6941473B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20010013094A1 (en) | 2001-08-09 |
| US6941473B2 (en) | 2005-09-06 |
| JP2001216161A (ja) | 2001-08-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3552627B2 (ja) | スタック保護システム、コンピュータシステム、コンパイラ、スタック保護方法および記憶媒体 | |
| US10002239B2 (en) | Data protection systems and methods | |
| Kiriansky et al. | Secure execution via program shepherding | |
| US7603704B2 (en) | Secure execution of a computer program using a code cache | |
| US7886148B2 (en) | Secure execution of a computer program | |
| US8458673B2 (en) | Computer-implemented method and system for binding digital rights management executable code to a software application | |
| US8239959B2 (en) | Method and data processing system to prevent manipulation of computer systems | |
| US8195953B1 (en) | Computer program with built-in malware protection | |
| US20110289586A1 (en) | Methods, systems, and media for detecting and preventing malcode execution | |
| US8635698B2 (en) | Antivirus system and method for removable media devices | |
| US20100064367A1 (en) | Intrusion detection for computer programs | |
| JP2007304954A (ja) | メモリ保護機能を有するコンピュータシステム | |
| US20080133858A1 (en) | Secure Bit | |
| CN114902178A (zh) | 域转换禁用配置参数 | |
| CN114692134A (zh) | 一种基于linux内核进程监控来保护代码及数据的系统和方法 | |
| Landwehr et al. | A taxonomy of computer program security flaws, with examples | |
| US20050198516A1 (en) | Intentional cascade failure | |
| US20040250086A1 (en) | Method and system for protecting against software misuse and malicious code | |
| KR101013419B1 (ko) | 시스템 보호 장치 및 방법 | |
| US20240126882A1 (en) | Instructions to process files in virtual machines | |
| US10452817B1 (en) | File input/output redirection in an API-proxy-based application emulator | |
| Kc et al. | CASPER: compiler-assisted securing of programs at runtime | |
| JPH0844556A (ja) | 電子計算機におけるセキュリティ、システム保護を行うソフトウェアの構造及び仕組み | |
| CN114902180A (zh) | 模间调用分支指令 | |
| CN117725583A (zh) | 基于虚拟机自省的Linux恶意代码检测方法与系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040127 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040329 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040420 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20040421 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040426 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080514 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |