範囲外の配列にアクセスすることはどれほど危険ですか？

（Cで）境界外の配列にアクセスすることはどれほど危険ですか？時々、配列の外から読み取ったり（プログラムの他の部分で使用されているメモリにアクセスしたり、それ以降であっても理解したり）したり、配列の外のインデックスに値を設定しようとしたりすることがあります。プログラムがクラッシュすることもありますが、実行されるだけで、予期しない結果しか得られません。

さて、私が知りたいのは、これは本当に危険なのでしょうか？それが私のプログラムにダメージを与えたとしても、それほど悪くはありません。一方、まったく関係のないメモリになんとかアクセスできたために、プログラムの外で何かが壊れた場合、それは非常に悪いと思います。私はたくさんの「何かが起こる可能性があります」、「セグメンテーションは最も悪い問題ではないかもしれません」、「ハードディスクがピンクに変わり、ユニコーンがウィンドウの下で歌っているかもしれない」と読みましたが、これは本当に良いことですが、本当に何が危険ですか？

私の質問：

1. 配列の外から値を読み取ると、プログラム以外の何かに損傷を与える可能性がありますか？物事を見ただけでは何も変わらないと思いますか、それとも、たとえばたまたま到達したファイルの「最後に開いた」属性を変更しますか？
2. 配列の外に値を設定すると、プログラム以外のものが損傷する可能性がありますか？このスタックオーバーフローの質問から、 どのメモリロケーションにもアクセスできること、安全性が保証されていないことがわかります。
3. XCode内から小さなプログラムを実行します。それは私のプログラムの周りにそれ自身のメモリの外に到達できない追加の保護を提供しますか？XCodeに害を及ぼす可能性はありますか？
4. 本質的にバグのあるコードを安全に実行する方法に関する推奨事項はありますか？

OSX 10.7、Xcode 4.6を使用しています。

ISO C標準（言語の公式定義）に関する限り、境界外の配列へのアクセスには「未定義の動作」があります。これの文字通りの意味は：

この国際標準が要件を課さない、移植不能またはエラーのあるプログラム構造またはエラーのあるデータの使用時の動作

非規範的なメモはこれを拡張します：

考えられる未定義の動作は、予測できない結果で完全に状況を無視することから、環境に特徴的な文書化された方法（診断メッセージの発行ありまたはなし）での動作またはプログラムの実行中、変換または実行の終了（発行あり）までさまざまです。診断メッセージ）。

それが理論です。現実は何ですか？

「最良の」ケースでは、現在実行中のプログラムが所有している（プログラムの誤動作を引き起こす可能性がある）、または現在実行中のプログラムが所有していない（おそらくプログラムを実行する）メモリにアクセスします。セグメンテーション違反のようなものでクラッシュします）。または、プログラムが所有するメモリに書き込もうとするかもしれませんが、それは読み取り専用とマークされています。これもおそらくプログラムをクラッシュさせるでしょう。

これは、同時に実行されているプロセスを互いに保護しようとするオペレーティングシステムでプログラムが実行されていることを前提としています。コードが「ベアメタル」で実行されている場合、たとえばそれがOSカーネルまたは組み込みシステムの一部である場合、そのような保護はありません。あなたの誤動作しているコードは、その保護を提供することになっているものです。その場合、ハードウェア（または近くの物や人）への物理的な損傷を含む、損傷の可能性がかなり大きくなります。

保護されたOS環境でも、保護は常に100％であるとは限りません。たとえば、権限のないプログラムがroot（管理）アクセス権を取得できるようにするオペレーティングシステムのバグがあります。通常のユーザー権限でも、誤動作しているプログラムは過剰なリソース（CPU、メモリ、ディスク）を消費し、システム全体をダウンさせる可能性があります。多くのマルウェア（ウイルスなど）は、バッファオーバーランを悪用して、システムに不正アクセスします。

（1つの歴史的な例：コアメモリを備えた一部の古いシステムでは、タイトループで単一のメモリ位置に繰り返しアクセスすると、文字どおりメモリのチャンクが溶けてしまう可能性があります。その他の可能性としては、CRTディスプレイの破壊や読み取りの移動などがあります/ドライブキャビネットの高調波周波数を持つディスクドライブの/ writeヘッドにより、テーブルを横切って床に落下します。

そして心配するスカイネットは常にあります。

つまり、意図的に何か悪いことをするプログラムを書くことができれば、少なくとも理論的には、バグのあるプログラムが同じことを誤って行う可能性があります。

実際には、それはだ非常に MacOS Xのシステム上で実行されている、あなたのバギーのプログラムがクラッシュよりも深刻何かをしようとしているとは考えにくいです。しかし、バグのあるコードが本当に悪いことをするのを完全に防ぐことは不可能です。

一般に、今日のオペレーティングシステム（とにかく人気のあるオペレーティングシステム）は、仮想メモリマネージャーを使用して、保護されたメモリ領域ですべてのアプリケーションを実行します。プロセスに割り当てられた/割り当てられた領域の外のREALスペースに存在する場所に単に読み書きすることは、ひどく簡単ではない（言う）ことがわかります。

直接的な答え：

1）読み取りによって別のプロセスが直接損傷を受けることはほとんどありませんが、プログラム/プロセスの暗号化、復号化、または検証に使用されるKEY値を読み取ると、間接的にプロセスに損傷を与える可能性があります。読み取るデータに基づいて意思決定を行っている場合、範囲外の読み取りは、コードに多少の悪影響/予期しない影響を与える可能性があります

2）メモリアドレスでアクセス可能なアクションに書き込むことで何かを実際に損傷させる唯一の方法は、書き込み先のメモリアドレスが実際にはハードウェアレジスタ（実際にはデータストレージではなく、一部を制御するための場所）である場合です。ハードウェアの）RAMの場所ではありません。事実、再書き込みできない（またはそのような性質の）一時的にプログラム可能な場所を書いていない限り、通常はまだ何かに損傷を与えることはありません。

3）通常、デバッガー内から実行すると、コードがデバッグモードで実行されます。デバッグモードで実行すると、実際には違法と見なされたり何か違法と見なされたりした場合に、コードをより速く停止する傾向があります（常にではありません）。

4）マクロを使用しないでください。既に配列インデックスの境界チェックが組み込まれているデータ構造などを使用してください。

さらに、上記の情報は、メモリ保護ウィンドウを備えたオペレーティングシステムを使用しているシステムにのみ当てはまることを付け加えておきます。組み込みシステム、またはメモリ保護ウィンドウ（または仮想アドレス指定ウィンドウ）を持たないオペレーティングシステム（リアルタイムまたはその他）を利用するシステム用のコードを作成する場合、メモリの読み取りと書き込みについてより多くの注意を払う必要があります。また、これらのケースでは、セキュリティの問題を回避するために、SAFEおよびSECUREコーディングプラクティスを常に採用する必要があります。

境界をチェックしないと、セキュリティホールなどの醜い副作用につながる可能性があります。醜いものの1つは任意のコード実行です。古典的な例：固定サイズの配列strcpy()があり、そこにユーザー指定の文字列を配置するために使用する場合、ユーザーは、バッファーをオーバーフローし、他のメモリ位置を上書きする文字列を与えることができます。終了します。

つまり、ユーザーがあなたのプログラムに本質的にを呼び出させる文字列をユーザーが送信できることを意味します。これは、exec("/bin/sh")それをシェルに変換し、すべてのデータの収集やマシンをボットネットノードに変換するなど、システムで必要なすべてを実行します。

これを行う方法の詳細については、楽しみと利益のためにスタックをスマッシングするを参照してください。

あなたが書く：

私はたくさんの「何かが起こる可能性がある」、「セグメンテーションが最も悪い問題ではないかもしれない」、「ハードディスクがピンクに変わり、ユニコーンがウィンドウの下で歌っているかもしれない」と読みましたが、これは本当に良いことですが、本当に何が危険ですか？

そのように言いましょう：銃を装填します。特に狙いを定めずに窓の外に向けて発砲します。危険は何ですか？

問題はあなたが知らないことです。コードがプログラムをクラッシュさせる何かを上書きする場合、定義された状態に停止するため、問題ありません。ただし、クラッシュしない場合、問題が発生し始めます。どのリソースがプログラムの制御下にあり、それらはそれらに何をするでしょうか？プログラムの制御下に置かれる可能性のあるリソースはどれですか。そのようなオーバーフローによって引き起こされた少なくとも1つの大きな問題を知っています。問題は、実稼働データベースのいくつかの無関係な変換テーブルをめちゃくちゃにする一見無意味な統計関数にありました。その結果、後で非常に費用のかかるクリーンアップが行われました。実際、この問題でハードディスクがフォーマットされていれば、はるかに安価で扱いやすいでしょう。言い換えると、ピンクのユニコーンが最も問題が少ないかもしれません。

あなたのオペレーティングシステムがあなたを保護するという考えは楽観的です。可能であれば、範囲外の書き込みを避けてください。

rootまたは他の特権ユーザーとしてプログラムを実行しなくても、システムに害が及ぶことはないので、一般的にこれは良い考えです。

ランダムなメモリの場所にデータを書き込むことにより、各プロセスが独自のメモリ空間で実行されるときに、コンピュータで実行されている他のプログラムに直接「ダメージ」を与えることはありません。

プロセスに割り当てられていないメモリにアクセスしようとすると、オペレーティングシステムにより、プログラムがセグメンテーション違反で実行されなくなります。

したがって、直接（ルートとして実行せず、/ dev / memなどのファイルに直接アクセスせずに）、プログラムがオペレーティングシステムで実行されている他のプログラムに干渉する危険はありません。

それにもかかわらず-そしておそらくこれは危険に関して聞いたものです-偶然にランダムなデータにランダムなデータを盲目的に書き込むことにより、あなたが損傷する可能性のあるものすべてに損傷を与える可能性があります。

たとえば、プログラムは、プログラムのどこかに保存されているファイル名で指定された特定のファイルを削除したい場合があります。誤ってファイル名が保存されている場所を上書きした場合、代わりに非常に異なるファイルを削除する可能性があります。

NSArray■Objective-Cの特定のメモリブロックが割り当てられます。配列の境界を超えると、配列に割り当てられていないメモリにアクセスすることになります。これの意味は：

1. このメモリには任意の値を設定できます。データがデータ型に基づいて有効かどうかを知る方法はありません。
2. このメモリには、秘密鍵やその他のユーザー資格情報などの機密情報が含まれている場合があります。
3. メモリアドレスが無効または保護されている可能性があります。
4. 別のプログラムまたはスレッドによってアクセスされているため、メモリの値は変化する可能性があります。
5. メモリマップされたポートなど、メモリアドレススペースを使用するものもあります。
6. 不明なメモリアドレスにデータを書き込むと、プログラムがクラッシュしたり、OSのメモリ空間が上書きされたりして、通常、太陽が内破する可能性があります。

プログラムの観点からは、コードが配列の境界を超えていることを常に知りたいと思っています。これにより、不明な値が返され、アプリケーションがクラッシュしたり、無効なデータが提供されたりする可能性があります。

コードをテストするときはmemcheck、Valgrindのツールを使用してみてください-スタックフレーム内の個々の配列境界違反をキャッチしませんが、微妙な、より広い範囲のメモリ問題を含む、他の多くの種類のメモリ問題をキャッチします。単一の関数の範囲外の問題。

マニュアルから：

Memcheckはメモリエラー検出器です。CおよびC ++プログラムで一般的な次の問題を検出できます。

• すべきでないメモリへのアクセス。たとえば、ヒープブロックのオーバーランおよびアンダーラン、スタックのトップのオーバーラン、解放後のメモリへのアクセス。
• 未定義の値、つまり初期化されていない値、または他の未定義の値から派生した値の使用。
• ヒープブロックの二重解放などのヒープメモリの不正な解放、またはmalloc / new / new []とfree / delete / delete []の使用の不一致
• memcpyおよび関連する関数でのsrcおよびdstポインターの重複。
• メモリリーク。

ETA：ただし、カズの答えが言うように、それは万能薬ではなく、特にエキサイティングなアクセスパターンを使用している場合は、常に最も役立つ出力を提供するわけではありません。

システムレベルのプログラミングや組み込みシステムのプログラミングを行う場合、ランダムなメモリ位置に書き込むと、非常に悪い事態が発生する可能性があります。古いシステムと多くのマイクロコントローラーはメモリマップされたIOを使用するため、特に非同期で行われる場合、ペリフェラルレジスタにマップされるメモリ位置への書き込みは大混乱を引き起こす可能性があります。

一例は、フラッシュメモリのプログラミングです。メモリチップのプログラミングモードは、チップのアドレス範囲内の特定の場所に特定のシーケンスの値を書き込むことで有効になります。それが進行中に別のプロセスがチップの他の場所に書き込むと、プログラミングサイクルが失敗します。

場合によっては、ハードウェアがアドレスを折り返す（アドレスの最上位ビット/バイトは無視される）ため、物理アドレス空間の終わりを超えてアドレスに書き込むと、実際にデータが書き込まれることになります。

そして最後に、MC68000のような古いCPUは、ハードウェアリセットだけでCPUを再び動作させることができるまでロックされます。数十年前からそれらに取り組んでいませんが、例外を処理しようとしたときにバスエラー（メモリが存在しない）が発生したときだと思います。ハードウェアリセットがアサートされるまで停止するだけです。

私の最大の推奨事項は、製品のあからさまなプラグインですが、私はそれに個人的な関心はなく、どのような方法でもそれらとは関係ありません。 Lintはこれらの種類のエラーを検出するだけでなく、悪い習慣について常に把握しているC / C ++プログラマーをより良いものにします。

また、誰かからコピーを入手できる場合は、MISRA Cコーディング標準を読むことをお勧めします。私は最近のものを見たことはありませんが、昔は、彼らがカバーしていることをするべき/すべきでない理由についての良い説明をしてくれました。

Dunnoはあなたについてですが、アプリケーションからコアダンプまたはハングアップを取得する2回目または3回目については、それを作成した会社の意見は半分になりました。4回目または5回目で、パッケージが何であれ棚物になり、パッケージ/ディスクの中央に木製の杭を打ち込み、それが私を悩ませることがないようにしています。

私はDSPチップ用のコンパイラーを使用しています。これは、そうではないCコードから配列の終わりを過ぎて1つにアクセスするコードを意図的に生成します！

これは、ループの構造が反復の終わりで次の反復のために一部のデータをプリフェッチするように構成されているためです。したがって、最後の反復の最後にプリフェッチされたデータは実際には使用されません。

このようなCコードを作成すると、未定義の動作が呼び出されますが、これは、最大限の移植性に関係する標準ドキュメントの形式にすぎません。

それよりも頻繁に、境界外にアクセスするプログラムは巧妙に最適化されていません。それは単にバギーです。コードはガベージ値をフェッチし、前述のコンパイラの最適化されたループとは異なり、コードはその後の計算でその値を使用するため、その値が破損します。

そのようなバグをキャッチする価値があるので、その理由だけでも動作を未定義にする価値があります。つまり、ランタイムが「main.cの42行目の配列オーバーラン」などの診断メッセージを生成できるようにします。

仮想メモリを備えたシステムでは、後に続くアドレスが仮想メモリのマップされていない領域にあるように、配列が割り当てられることがあります。アクセスにより、プログラムが攻撃されます。

余談ですが、Cでは配列の最後を過ぎたポインタを作成することが許可されていることに注意してください。そして、このポインターは、配列の内部へのどのポインターよりも大きく比較する必要があります。これは、Cの実装ではメモリの最後に配列を配置できないことを意味します。この場合、1つのプラスアドレスが折り返され、配列内の他のアドレスよりも小さく見えます。

それにもかかわらず、初期化されていない値または範囲外の値へのアクセスは、最大限の移植性がなくても、有効な最適化手法である場合があります。これは、たとえば、Valgrindツールが初期化されていないデータへのアクセスを報告しないのは、これらのアクセスが発生したときではなく、後でプログラムの結果に影響を与える可能性がある何らかの方法で値が使用された場合のみです。「xxx：nnnの条件付きブランチは初期化されていない値に依存しています」のような診断が表示され、発生元を追跡するのが難しい場合があります。このようなすべてのアクセスがすぐにトラップされると、コンパイラーによって最適化されたコードだけでなく、正しく手動で最適化されたコードからも多くの誤検知が発生します。

そういえば、Linuxに移植してValgrindで実行すると、これらのエラーが発生するベンダーのコーデックを使用していました。しかし、ベンダーは私にいくつかのビットだけが実際に使用されている値の一部は初期化されていないメモリからのものであり、それらのビットはロジックによって慎重に回避されました。値の適切なビットのみが使用されており、Valgrindには個々のビットを追跡する機能がありません。初期化されていない素材は、エンコードされたデータのビットストリームの終わりを超えて単語を読み取ることで得られましたが、コードはストリーム内のビット数を認識しており、実際よりも多くのビットを使用しません。ビットストリームアレイの末尾を超えてアクセスしても、DSPアーキテクチャに害を及ぼすことはありません（アレイの後に仮想メモリはなく、メモリマップされたポートはなく、アドレスはラップしません）。これは有効な最適化手法です。

ISO Cによると、C規格で定義されていないヘッダーを単に含めるか、プログラム自体またはC規格で定義されていない関数を呼び出すことが未定義の例であるため、「未定義の動作」はそれほど意味がありません動作。未定義の動作は、「地球上の誰によっても定義されていない」という意味ではなく、単に「ISO C標準によって定義されていない」という意味です。しかし、もちろん、時には未定義の動作が本当にされ、絶対に誰もが定義されていません。

あなた自身のプログラム以外には何も壊さないと思います、最悪の場合、カーネルがプロセスに割り当てなかったページに対応するメモリアドレスから読み書きしようとし、適切な例外を生成します殺される（つまり、あなたのプロセス）。