Cがバッファオーバーフローを起こしにくくするのはなぜ難しいのですか？

私は大学でコースを行っています。ラボの1つでは、提供されたコードに対してバッファオーバーフローエクスプロイトを実行しています。これは、スタック上の関数の戻りアドレスを変更して別の関数に戻るなどの単純な悪用から、プログラムのレジスタ/メモリ状態を変更してから呼び出した関数に戻るコードまでの範囲です。あなたが呼び出した関数は、エクスプロイトを完全に忘れています。

私はこれについていくつか調査を行いましたが、この種のエクスプロイトは、Wiiでhomebrewを実行したり、iOS 4.3.1のテザーなしのジェイルブレイクを実行したりするなど、今でもどこでも使用されています。

私の質問は、なぜこの問題を修正するのがとても難しいのですか？これが何百ものものをハッキングするために使用される主要なエクスプロイトの1つであることは明らかですが、許可された長さを超えて入力を切り捨て、取得したすべての入力を単純にサニタイズするだけで修正するのは非常に簡単だと思われます。

編集：私は考慮すべき答えが欲しい別の視点-なぜCの作成者はライブラリを再実装することでこれらの問題を修正しないのですか？

彼らはライブラリを修正しました。

現代の任意のC標準ライブラリは、より安全な亜種が含まれstrcpy、strcat、sprintf、などを。

最ものUnixである- - C99システムではあなたのような名前でこれらを見つけるstrncatとsnprintf、「n」は、それがバッファのサイズやコピーへの要素の最大数です引数を取ることを示しています。

これらの関数は、多くの操作をより安全に処理するために使用できますが、振り返ってみると、それらの操作性は大きくありません。たとえば、一部のsnprintf実装では、バッファーがnullで終了することを保証しません。strncatコピーするためにいくつかの要素を取りますが、多くの人が誤ってdestバッファのサイズを渡します。

Windowsでは、1はしばしば見つけstrcat_s、sprintf_s「安全」を示す、「_s」サフィックスを。これらもC11のC標準ライブラリに組み込まれ、オーバーフローが発生した場合に発生する処理（切り捨てとアサートなど）をより細かく制御できます。

多くのベンダーasprintfは、GNU libcのようにさらに適切なサイズのバッファーを自動的に割り当てる非標準の代替手段を提供しています。

「ただCを修正する」ことができるという考えは誤解です。Cを修正することは問題ではなく、すでに行われています。問題は、無知な、疲れた、または急いでいるプログラマーによって書かれた何十年ものCコード、またはセキュリティが重要でないコンテキストからセキュリティが重要なコンテキストに移植されたコードを修正することです。標準のライブラリを変更してもこのコードを修正することはできませんが、新しいコンパイラや標準のライブラリに移行すると、問題を自動的に特定できる場合があります。

Cが設計上「エラーを起こしやすい」と言っても、実際には不正確ではありません。のようないくつかの重大な間違いは別getsとして、C言語は、そもそも人々をCに引き寄せる主要な機能を失うことなく、他の方法にはなり得ません。

Cは、一種の「ポータブルアセンブリ」として機能するシステム言語として設計されました。C言語の主要な機能は、高レベル言語とは異なり、Cコードが実際のマシンコードに非常に密接にマッピングされることが多いことです。言い換えれば、++i通常は単なるinc命令であり、多くの場合、Cコードを調べることで、実行時にプロセッサが何を行うかについての一般的なアイデアを得ることができます。

しかし、暗黙的な境界チェックを追加すると、余分なオーバーヘッドが多く追加されます。オーバーヘッドはプログラマが要求しなかったものであり、望ましくない場合があります。このオーバーヘッドは、各アレイの長さを保存するために必要な追加のストレージ、またはすべてのアレイアクセスでアレイの境界をチェックするための追加の命令をはるかに超えています。ポインター演算はどうですか？または、ポインターを受け取る関数がある場合はどうなりますか？ランタイム環境には、そのポインターが正当に割り当てられたメモリブロックの境界内にあるかどうかを知る方法がありません。これを追跡するには、現在割り当てられているメモリブロックのテーブルに対して各ポインターをチェックできる本格的なランタイムアーキテクチャが必要です。この時点で、すでにJava / C＃スタイルの管理されたランタイム領域に到達しています。

私は本当の問題は、これらの種類のバグを修正するのが難しいということではなく、それらを作るのがとても簡単だと思います：を使用する場合strcpy、sprintfそして友人が（一見）最も簡単な方法で動作するなら、あなたはおそらくバッファオーバーフローのドアを開けました。そして、誰かがそれを悪用するまで誰も気付かないでしょう（あなたが非常に良いコードレビューを持っている場合を除いて）。ここで、多くの平凡なプログラマーがいて、ほとんどの場合、時間的なプレッシャーにさらされているという事実を追加します。そして、バッファーオーバーフローに悩まされるコードのためのレシピがあり、単にすべてを修正するのは難しいでしょうそれらの多くと彼らはとてもよく隠れています。

Cは、問題に対処するための有用なツールを事実上提供しないため、バッファオーバーフローを修正することは困難です。これは、ネイティブのバッファが何の保護を提供しないことを基本的な言語の欠陥だと C ++がでやったようにそれは、優れた製品とそれらを置き換えるために、事実上完全でない、不可能だstd::vectorとstd::array、そしてそれがバッファオーバーフローを見つけるためにも、デバッグモードでは難しいです。

問題はC 言語にはありません。

IMO、克服すべき唯一の主要な障害は、Cがただひどく教えられているということです。何十年もの悪い習慣や間違った情報がリファレンスマニュアルや講義ノートに制度化され、新しい世代のプログラマーの頭を最初から傷つけていました。学生には、gets¹やscanfなどの「簡単な」I / O機能の簡単な説明が与えられ、その後、自分のデバイスに任されます。それらは、それらのツールが失敗する可能性のある場所や方法、またはそれらの失敗を防ぐ方法を教えられていません。これらは、使用について語られていないfgetsとstrtol/strtodこれらは「高度な」ツールと見なされているためです。その後、彼らは彼らの大混乱をもたらすために、プロの世界で解き放たれます。同じ脳損傷を受けた教育を受けたため、経験豊富なプログラマーの多くがこれ以上良く知っているわけではありません。それは気違いです。ここやStack Overflowや他のサイトでは、質問をしている人が自分が話していることを知らないだけの人に教えられていることが明らかになっているので、もちろんたくさんの質問があります。「教授は間違っています」彼は教授であり、あなたはインターネット上の単なる男だからです。

そして、あなたは「まあ、言語標準に従って...」で始まる答えを軽disする群衆を持っています。なぜなら彼らは現実の世界で働いており、彼らによれば標準は現実の世界には適用されないからです。私はただ悪い教育を受けた人に対処することができますが、無知であることを主張する人は誰でも業界での苦境です。

安全なコードを書くことに重点を置いて言語を正しく教えれば、バッファオーバーフローの問題はありません。それは「ハード」ではなく、「高度」ではなく、ただ注意しているだけです。

はい、これは暴言でした。

この問題は、プログラマーの無能さよりも管理上の近視の問題の1つです。90,000行のアプリケーションでは、完全に安全ではない安全でない操作が1つだけ必要です。基本的に安全でない文字列処理の上に記述されたアプリケーションが100％完璧になる可能性の領域をほぼ超えています-つまり、安全でないことを意味します。

問題は、安全でないことの費用が正しい受取人に請求されないこと（アプリを販売する会社が購入価格を払い戻す必要がほとんどないこと）、または決定が下された時点ではっきりと見えないことです（「出荷する必要があります3月になっても！」）。長期的なコストと企業の利益ではなくユーザーのコストを考慮した場合、Cまたは関連言語で書くのははるかに高価であり、おそらく非常に高価であるため、多くの人にとって明らかに間違った選択であると確信しています今日の慣習的な知恵がそれが必要であると言う分野。しかし、より厳しいソフトウェア責任が導入されない限り、それは変わりません-業界の誰も望んでいません。

Cを使用する大きな利点の1つは、Cを使用すると、適切と思われる方法でメモリを操作できることです。

Cを使用することの大きな弱点の1つは、Cが適切と思われる方法でメモリを操作できることです。

安全でない機能には安全なバージョンがあります。ただし、プログラマーとコンパイラーは厳密にその使用を強制しません。

Cの作成者がライブラリを再実装してこれらの問題を修正しないのはなぜですか？

おそらくC ++がすでにこれを行っており、Cコードとの下位互換性があるためです。したがって、Cコードで安全な文字列型が必要な場合は、std :: stringを使用し、C ++コンパイラを使用してCコードを記述します。

基礎となるメモリサブシステムは、ガードブロックとそれらの有効性チェックを導入することにより、バッファオーバーフローを防ぐのに役立ちます。したがって、すべての割り当てに4バイトの「fefefefe」が追加されます。メモリへの書き込みを防ぐことは保証されていませんが、何かが間違っており、修正する必要があることを示します。

問題は、古いstrcpyなどのルーチンがまだ存在していることだと思います。それらがstrncpyなどを支持して削除された場合、それは助けになります。

オーバーフローの問題が修正されない理由を理解するのは簡単です。Cはいくつかの領域で欠陥がありました。当時、これらの欠陥は許容できるものであるか、機能であるとさえ考えられていました。数十年後、これらの欠陥は修正不可能になりました。

プログラミングコミュニティの一部は、これらの穴を塞ぐことを望んでいません。文字列、配列、ポインター、ガベージコレクションから始まるすべてのフレーム戦争を見てください...