Javaにはバッファオーバーフローがありますか? はいの場合、シナリオを教えていただけますか?
10 に答える
Java 文字列は char 配列に基づいており、Java は配列の境界を自動的にチェックするため、バッファ オーバーフローは異常なシナリオでのみ発生する可能性があります。
- JNI経由でネイティブコードを呼び出す場合
- JVM 自体 (通常は C++ で記述)
- インタープリターまたは JIT コンパイラーが正しく機能しない (Java バイトコードで必須の境界チェック)
Java や C# などのマネージ言語にはこれらの問題はありませんが、実際にコードを実行する特定の仮想マシン (JVM/CLR/etc) には問題がある可能性があります。
すべての意図と目的のために、いいえ。
Javaには、割り当てられた配列の外側の領域からデータにアクセスできないことを確認する配列境界チェックがあります。配列のサイズを超える領域にアクセスしようとすると、ArrayOutOfBounds
例外がスローされます。
バッファ オーバーランがある場合、それはおそらく Java 仮想マシンのバグによるものであり、私の知る限りでは、Java 言語仕様や Java 仮想マシン仕様に書かれている意図した動作ではありません。
はいといいえ。いいえ、マネージド メモリ モデルであるため、誤ってバッファ オーバーフローの脆弱性にさらされることはありません。ただし、JVM および JDK にはバッファ オーバーフローの脆弱性が存在する可能性があります。この Secunia アドバイザリを参照してください。
http://secunia.com/advisories/25295
または、以前のいくつかの JDK および JRE の脆弱性に関するこれらの古いアドバイザリを参照してください。
Java ランタイム環境 (JRE) の「unpack200」JAR アンパック ユーティリティの整数およびバッファ オーバーフローの脆弱性により、権限がエスカレーションされる可能性があります https://download.oracle.com/sunalerts/1020225.1.html
「unpack200」JAR アンパック ユーティリティを使用してアンパック アプレットおよび Java Web Start アプリケーションを使用する Java ランタイム環境 (JRE) の整数およびバッファ オーバーフローの脆弱性により、信頼されていないアプレットまたはアプリケーションが権限をエスカレートできる可能性があります。たとえば、信頼できないアプレットは、信頼できないアプレットを実行しているユーザーがアクセスできるローカル ファイルの読み取りと書き込み、またはローカル アプリケーションの実行のアクセス許可を自分自身に付与する場合があります。
Sun は、iDefense VCP ( http://labs.idefense.com/vcp/ ) と協力している "regenrecht"と Google の Chris Evans に、これらの問題を私たちに知らせてくれたことに感謝の意を表します。
Sun Java Development Kit (JDK) および Java Runtime Environment (JRE) に複数の脆弱性が確認されています。https://security.gentoo.org/glsa/200705-23
「システム クラスの不正な使用」に関連する詳細不明の脆弱性が、富士通セキュリティ チームによって報告されました。さらに、Google Security Team の Chris Evans は、JPG または BMP ファイルで使用される ICC パーサーでバッファ オーバーフローを引き起こす整数オーバーフローと、特定の BMP ファイルを処理する際の /dev/tty への不正な open() 呼び出しを報告しました。
スタックまたはヒープ自体を上書きするという厳密な意味でのバッファ オーバーフローには、次のいずれかが必要です。
- フレームワークのバグ (これらは過去に存在し、今後も発生する可能性があります)
- JNI の使用 (基本的にマネージ コードを使用しなくなりました)
バッファを使用するコードがあり、コードがそれを正しく解析する責任があるが、そうできないという意味でのバッファ オーバーフローが発生する可能性があります。たとえば、XML パーサーを作成すると、パーサーの設計により、以前に検証されたデータがペイロードで上書きされ、アプリケーションの動作が悪くなるような、不正な形式の (または正当だが一般的ではない) 要求が誰かから提供される可能性があります。
この後者の形式はあまりありそうにありませんが、SQL 文字列クレンジング関数が広く配布されており、このような問題が魅力的なターゲットになる可能性があります。
Java (および .Net) 仮想マシンは、予約済みメモリの外に書き込もうとするコードをキャッチします。これを正しく処理しないアプリケーションは、依然としてセキュリティ上の問題を引き起こす可能性があります。悪意のあるユーザーが無効な入力を入力して例外をトリガーできる場合、サービス拒否攻撃などを行うことができます。
メソッドが、通常は整数のオーバーフローを介して、意図していない配列の有効なエントリに書き込むことができます。
たとえば、境界をチェックするには以下では不十分です。
/* !! WRONG !! */ 0 <= off && 0 <= len && off+len <= buff.length /* !! WRONG !! */
IIRCには、StringBuffer
かつてそのようなバグがありましたが、それを使ってできることは何もありませんでした。
Java Native Interace(JNI)機能を使用して外部コードを呼び出していて、外部コードに悪用可能な問題があった場合、Javaプログラムでバッファオーバーフローが発生する可能性があります。ほとんどのアプリケーションは可能な限りJNIの使用を避けているため、これはかなりまれです。
すでに指摘したように、Java は言語として、すべてのメモリ アクセスの境界チェックを行っており、ここでエラーが発生した場合は、プログラムではなく JVM に問題があります。ただし、注意すべき点は、Java のメモリ リークと同様の議論です。スタックを破壊することはできませんが、適切に処理されない間違った場所で ArrayOutOfBoundsException が発生すると、システムが台無しになる可能性があります。