バッファオーバーフロー-Wikipedia

バッファオーバーフロー （ 英語 バッファオーバーフロー ）または – 特に – また スタックオーバーフロー （英語 、 スタックオーバーフロー ‘ ）現在のソフトウェアで最も一般的なセキュリティギャップの1つであると呼ばれます。インターネットを悪用することができます。基本的にバッファーがオーバーフローした場合、プログラム内のプログラム内のデータが多すぎると予約済みのメモリ領域に書き込まれます。バッファーまたはスタックは、ターゲットストレージ領域に従って横たわるストレージポイントを上書きするために使用されます。

バッファーの外側の望ましくない書き込みの原因は、特大の量のデータであるだけでなく、宛先アドレスのオーバーフロー（またはその他の誤った計算）でもあります。この場合、1つ 、 ポインターオーバーフロー ‘ （英語から ポインター 、「ポインター」の場合）。

バッファオーバーフローは、関連するプログラムのクラッシュ、データの偽造、環境環境という用語のデータ構造に損傷を与える可能性があります。後者は、任意のデータを使用してサブルーチンの返品アドレスを上書きすることができます。つまり、攻撃者は、マシンコードを送信することによりオーバーフローオーバーフローの影響を受けやすいプロセスの特権で任意のコマンドを実行できます。このコードには通常、攻撃者にシステムへのより快適なアクセスを提供するという目標があり、その目的でシステムを使用できるようにします。広範囲にわたるサーバーとクライアントソフトウェアのバッファオーバーフローも、インターネットワームで使用されます。

ルートアクセスは、特にUNIXシステムで求められており、攻撃者にすべてのアクセス権を与えます。ただし、これは、「通常の」ユーザーの特権につながるバッファーオーバーフローが無害であることを誤解した頻度を意味するものではありません。すでにユーザーの権利（右翼拡張機能、英語）がある場合、切望されているルートアクセスに到達することは、しばしばはるかに簡単です。 特権エスカレーション ）。

バッファオーバーフローによる攻撃は、コンピューターの安全性とネットワークセキュリティにおける重要なトピックです。これらは、あらゆる種類のネットワークだけでなく、ローカルでもシステムで試すことができます。原則として、それらは短期間で配達されたメーカー（パッチ）によってのみ改善されます。

プログラミングの過失に加えて、同じメモリのデータとプログラムに従って、Von-Neumannアーキテクチャに基づいたコンピューターシステムによってバッファオーバーフローが可能になります。このハードウェアの縫い目により、あなたは組み立てられたプログラミング言語またはコンパイルされた言語の下での問題にすぎません。インタープリターのエラーに加えて、データのストレージ領域は常に通訳を完全に制御しているため、解釈された言語は通常影響を受けません。

バッファオーバーフローの最も重要な原因は、ストレージエリアの領域のオーバーランを防ぐために、メモリ領域の限界を自動的に監視する可能性を提供しないプログラミング言語の使用です。これには、パフォーマンス（およびもともとコンパイラのシンプルさ）に主な重みを置き、監視を分配する言語Cが含まれます。また、C-Further開発C ++が含まれます。ここでは、プログラマーは対応するコードを手作業で生成することを部分的に強制されます。これらのプログラムパーツは通常、プログラムテスト中にテストされていないか、不十分であるため、レビューも故障していることがよくあります。さらに、（C ++の場合）複雑な言語範囲と標準ライブラリは、多くのエラーが発生するコンストラクトを提供します。

頻繁に使用されるプログラミング言語C ++は、フィールドの境界を自動チェックするための限られたオプションのみを提供します。プログラミング言語cのさらなる開発として、Cの最も多くの特性を引き継ぎますが、最新の言語エージェント（自動メモリ管理を含む）を使用する場合の緩衝オーバーフローのリスクはほとんど回避できます。習慣、既存のCコードの互換性の理由、Cコンベンションでのシステムコール、およびパフォーマンス上の理由のために、これらのオプションが常に使用されるとは限りません。 PascalやADAなどの言語とは対照的に、ランタイムレビューは言語の一部ではなく、一部のアプリケーションで改造することができます（例：スマートポインターを使用）。

ほとんどのプログラミング言語は標準ライブラリも定義するため、言語の選択は通常、対応する標準ライブラリの使用も意味します。 CおよびC ++の場合、標準的なライブラリには多くの危険な機能が含まれており、その一部は安全な使用を許可しておらず、代替手段はありません。

プログラミング言語レベルでは、C ++またはCよりも概念的に安全なプログラミング言語を使用して、バッファオーバーフローのリスクを削減または除外することができます。たとえば、はるかに低いリスクは、Pascalファミリーモジュラ、オブジェクトパスカル、またはADAのプログラミング言語です。

バイテコードでの実行が監視されるため、たとえばプログラミング言語Javaでは、バッファーオーバーフローはほとんど除外されます。しかし、Javaにはバッファオーバーフローがあり、その原因は実行時間システムにあり、その原因はいくつかのJREバージョンが影響を受けます。 ^{[初め] [2]} 一方、Javaランタイム環境は1つをスローします Java.lang.StackoverFlowerror メソッドコールアップが誤った無限の再帰を介してオーバーフローする場合。これは、実行時間システムではなく、アプリケーションプログラマの論理プログラミングエラーです。

CおよびC ++のその他の特性、および最も頻繁に使用されるプロセッサにより、バッファーオーバーフローの発生が可能になります。これらの言語のプログラムは、部分的にサブプログラムで構成されています。これらにはローカル変数があります。

最新のプロセッサでは、スタックと呼ばれる領域にサブルーチンとそのローカル変数の返品アドレスを配置することが一般的です。サブプログラム呼び出し 初め 返品アドレスと その後 ローカル変数をスタックに配置しました。 Intel Pentiumなどの最新のプロセッサでは、スタックは構築されたプロセッサコマンドによって管理され、成長しています 下向き 。フィールドまたは文字列がローカル変数で使用されている場合、これらは通常 上 説明された。フィールド制限がチェックされていない場合、フィールドを超えてスタックの返品アドレスに到達し、必要に応じて故意に変更するために使用できます。

同様の形でよく使用されるCの次のプログラムは、そのようなバッファーオーバーフローを示しています。

空所  input_line （）  {   char  ライン [ 1000 ];   もしも  （ 取得 （ ライン ）））  //配列のポインターを受信し、長さの情報はありません   プット （ ライン ）;  // putsラインの内容をstdoutに書き込みます  }  

スタックを下に説明するプロセッサでは、これは呼び出す前に見ます 取得 （cからの標準ライブラリの関数）この方法で（既存のベースポインターを控える場合 ^[3] ）：

スタックが成長し、変数は上向きに上方に上がります

取得 入力から行を読み、文字を書き留めます 線[0] スタック内。ラインの長さを確認しません。 cのセマンティクスによると 取得 ポインターとしてのメモリアドレスのみですが、利用可能な長さに関する情報はありません。 1004文字を入力すると、最後の4バイトが返信アドレスを上書きします（アドレスがここに4バイトであると仮定して）。これはスタック内のプログラムに向けられます。最初の1000文字では、必要に応じて適切なプログラムに入ることができます。

00@45ea/％a@4 … … … … … … … … … … … … … … … 0A＆％

Enter、stack（1004文字）に書かれたものが書かれています

スタック内の返品アドレスとプログラムコードを上書きする

プログラムがユーザーよりも高い特権を持っている場合、特別な入力でバッファオーバーフローを使用してこれらの特権を取得できます。

プログラムの位置 [ 編集 | ソーステキストを編集します ]

非常に持続可能な対策は、タイプセーフプログラミング言語とJavaやC＃などのツールを使用することで構成されます。このツールでは、コンパイラで機械言語に翻訳するときに割り当てられたメモリ領域のコンプライアンスが確認される場合がありますが、最新のプログラムコードを使用して最新のものです。ポインター変数の変更は、厳格で制限的なルールに従ってのみ実行されることが不可欠です。この文脈では、実行時間システムのみが自動ストレージクリーニングを実行する場合にも役立ちます。

プログラムを作成するときは、すべてのフィールド境界のレビューに注意を払う必要があります。これは、時代遅れの非タイプセーフプログラミング言語を持つプログラマーの責任です。ただし、フィールドの境界を自動的に監視するプログラミング言語の使用を考慮する必要がありますが、これは常に可能ではありません。 C ++を使用する場合、Cスタイルフィールドの使用は可能な限り回避する必要があります。

空所  input_line （）  {   char  ライン [ 1000 ];   もしも  （ fgets （ ライン 、  のサイズ （ ライン ）、、  stdin ）））  // fgetsは長さをチェックします   プット （ ライン ）;  // putsラインの内容をstdoutに書き込みます  }  

対策：FGETSは入力長をチェックします

プログラムコードの確認 [ 編集 | ソーステキストを編集します ]

特別なレビューツールを使用すると、コードを分析し、可能性のある弱点を発見できます。ただし、フィールド制限のコードは間違っている可能性があり、多くの場合、テストされていません。

コンパイラからのサポート [ 編集 | ソーステキストを編集します ]

既存のプログラムの非常に大きな選択は、CおよびC ++で利用できます。新しいバージョンのようなモダンなコンパイラー GNU C-Compilers 翻訳でチェックコードの生成のアクティブ化を許可します。

設計により、Cのような言語は常にフィールドの境界をチェックすることを許可するとは限りません（例： 取得 ）。コンパイラは、他の方法を作成する必要があります。乱数（「カナリア」とも呼ばれます）の場合、返信アドレスとローカル変数スペースの間に追加します。この数値は、プログラムの開始時に決定され、毎回異なる値を取得します。各サブプログラム呼び出しで、乱数は提供されたエリアに記述されます。コンパイラは、必要なコードを自動的に生成します。プログラムを返信アドレスから離れる前に、コンパイラコードは意図した値の乱数を挿入します。変更された場合、返信アドレスも信頼できません。プログラムは、対応するメッセージでキャンセルされます。

対策：乱数障壁

さらに、一部のコンパイラに コピー ローカルフィールドの下に戻るアドレスを生成します。このコピーは、リターンを使用すると使用されます。バッファオーバーフローの利用は非常に困難です。

対策：返品アドレスのコピー

たとえば、GNUコンパイラコレクションには、上記のような測定値を実装する2つの広範な拡張機能があります。

a ヒープオーバーフロー ヒープで発生するバッファオーバーフローです。ヒープ上のストレージは、malloc（）や 新しい -C ++のオペレーター。ヒープデータのデータが長さをチェックせずにバッファーで記述され、データの量がバッファのサイズよりも大きい場合、バッファの端を超えて記述され、メモリオーバーフローがあります。

終えた ヒープオーバーフロー 特にヒープを実行できる場合、ポインターからコンピューター上の任意のコードの機能に上書きすることで実行できます。たとえば、Freibsdにはヒープ保護がありますが、これはここでは不可能です。バッファーアクセス中に長さのレビューが行われないプログラミング言語にのみ表示できます。 C、C ++、またはアセンブラーは敏感で、JavaまたはPerlはそうではありません。

2015年6月23日に、Adobeは、マリスコードのこのようなバッファオーバーフローをシステムで実行し、フラッシュプレーヤーがインストールされたシステムの制御を実行できることを発表しました。 ^{[4] [5]}

#define bufsize 128  char  *  copy_string （ const  char  * s ））  {   char  *  buf  =  マロック （ バフレス ）;  //仮定：長い文字列は決して発生しません   もしも  （ buf ））   strcpy （ buf 、  s ）;  //戦略の場合はヒープオーバーフロー> 127   戻る  buf ;  }  

strcpy（）はソースと目標のサイズをチェックしないが、ゼロ決定（ ”）メモリ領域をソースとして予想するため、次のバリアントも不明です（ただし、「buf」の上で撮影されていませんが、「s」が割り当てられたメモリ領域の端に必要な場合は撃ちます）。

char  *  buf ;  buf  =  マロック （ 初め  +  ストライク （ s ））;  //プラス1は、NUL標識が終了したためです  もしも  （ buf ））   strcpy （ buf 、  s ）;  

一方、strncpyコマンドは、ソースから宛先までの最大n文字をコピーするため、bufsizeよりもゼロ状態または大きい場合に機能します。

char  * buf ;  もしも  （（） buf  =  マロック （ バフレス ）））  ！=  ヌル ））  {  //ポインターのチェック。   strncpy （ buf 、  s 、  バフレス   -   初め ）;   buf [ バフレス   -   初め ]  =  '' ;  //短所：文字チェーンは手動でスケジュールする必要があります。  }  戻る  buf ;  

一部のオペレーティングシステム、例えばB. OpenBSD、機能を提供します stlcpy これにより、目的地がゼロで終了し、カットオフターゲティングの認識が簡素化されます。

• アレフ・ワン： 楽しさと利益のためにスタックを破壊します 。 の： フラックマガジン。 7、No。49（この記事では、バッファオーバーフローの作用モードを示しています）。
• Jon Erickson: 禁止コード。 MITP、Bone 2004、ISBN 3-8266-1457-7。
• トビアス・クライン： バッファオーバーフローとフォーマットストリング弱いスポット。機能的、エクスプロイト、および対策。 Dpunkt、Heidelberg 2004、ISBN 3-89864-192-9。
• フェリックス・リンドナー： リスクの束。ヒープのバッファオーバーフローとそれらの使用方法。 の： Cではありません。コンピューターテクノロジーの雑誌。 23、9、2006、S。186–192、 また、Heise Securityでオンラインで無料です 。
• オリバー・ミュラー： 卸売業者。スタックオーバーフロー経由のシステムスランプ。 の： IX-専門情報技術のための雑誌。 バンド2、2007、S。100–105。
• Stephan Kallnik、Daniel Pape、DanielSchröter、Stefan Strobel、Daniel Bachfeld： 実行されました。バッファオーバーフローおよびその他のターゲット破損ポイント 。 また、セキュリティもheise Cではありません 23/2001、S。216 （ 記念 2001年11月14日から インターネットアーカイブ ）。 Cの簡単な例を掲載した入門記事

1. ↑ 太陽ジャバランタイム環境の弱点 – LinuxCommunity 、2007年1月17日
2. ↑ Sun Java JREまで1.5.x GIFイメージハンドラーバッファーオーバーフロー – vulldb.com 、2007年1月22日（2015年7月7日の最後の変更）
3. ↑ スタックとは何ですか？ 。 2. 2012年6月。
4. ↑ Dennis Schirrmacher： Adobe：フラッシュプレーヤーの緊急更新。 の： セキュリティを重視します。 ハイズオンライン、2015年6月24日、 2015年6月29日にアクセス 。
5. ↑ Adobe Flashプレーヤーが利用できるセキュリティアップデート – CVE番号：CVE​​-2015-3113。 の： Adobe Security Bulletin。 Adobe Inc.、2015年6月23日、 2015年6月29日にアクセス 。