Does Java have buffer overflows?

Does Java have buffer overflows? If yes can you give me scenarios?

Since Java Strings are based on char arrays and Java automatically checks array bounds, buffer overflows are only possible in unusual scenarios:

1. If you call native code via JNI
2. In the JVM itself (usually written in C++)
3. The interpreter or JIT compiler does not work correctly (Java bytecode mandated bounds checks)

Managed languages such as Java and C# do not have these problems, but the specific virtual machines (JVM/CLR/etc) which actually run the code may.

For all intents and purposes, no.

Java has array bounds checking which will check that data cannot be accessed from area outside of the allocated array. When one tries to access area that is beyond the size of the array, an ArrayOutOfBounds exception will be thrown.

If there is a buffer-overrun, it is probably from a bug in the Java Virtual Machine, and is, to my knowledge, not the intended behavior that is written in the Java Language Specifications nor the Java Virtual Machine Specifications.

Yes and no. No, in that you cannot really create mistakenly open yourself up to a buffer overflow vulnerability because it is a managed memory model. However, there can be buffer overflow vulnerabilities in the JVM and JDK. See this Secunia advisory:

http://secunia.com/advisories/25295

Or see these old advisories on several previous JDK and JRE vulnerabilities:

• Integer and Buffer Overflow Vulnerabilities in the Java Runtime Environment (JRE) "unpack200" JAR Unpacking Utility May Lead to Escalation of Privileges https://download.oracle.com/sunalerts/1020225.1.html

> Integer and buffer overflow vulnerabilities in the Java Runtime > Environment (JRE) with unpacking applets and Java Web Start > applications using the "unpack200" JAR unpacking utility may allow an > untrusted applet or application to escalate privileges. For example, > an untrusted applet may grant itself permissions to read and write > local files or execute local applications that are accessible to the > user running the untrusted applet. > > Sun acknowledges with thanks, "regenrecht" working with the iDefense > VCP (http://labs.idefense.com/vcp/) and Chris Evans of Google for > bringing these issues to our attention.

• Multiple vulnerabilities have been identified in Sun Java Development Kit (JDK) and Java Runtime Environment (JRE). https://security.gentoo.org/glsa/200705-23

> An unspecified vulnerability involving an "incorrect use of system > classes" was reported by the Fujitsu security team. Additionally, > Chris Evans from the Google Security Team reported an integer overflow > resulting in a buffer overflow in the ICC parser used with JPG or BMP > files, and an incorrect open() call to /dev/tty when processing > certain BMP files.

A buffer overflow in the strict sense of overwriting the stack or heap itself would require either:

1. A bug in the framework (these have existed in the past and may well again)
2. The use of JNI (essentially no longer using managed code)

A buffer overflow in the sense that you have code using a buffer and your code is responsible for parsing it correctly but fail to do so is possible. For example You might write an XML parser and someone could provide you with a malformed (or legitimate but uncommon) request which, owing to the design of your parser overwrites previously validated data with some payload that would cause your application to behave badly.

This latter form is less likely but a poorly written sql string cleansing function widely distributed that had a problem such as this would be an inviting target.

Java (and .Net) virtual machines catch code that tries to write outside of reserved memory. Applications that don't handle this correctly can still cause security problems. If malicious users can trigger exceptions by entering invalid input they can do denial of service attacks for example.

As has already been pointed out, Java has, as a language, bounds checking on all memory access, and if there's an error here, the JVM is at fault and not the program. However, what should be noted, which is a similar argument to memory leaks in Java; while not possible to smash the stack, an ArrayOutOfBoundsException in the wrong place, which is not handled correctly, may still end up screwing up your system.

You could conceivably cause a buffer overflow in a Java program if you were using the Java Native Interace (JNI) facility to invoke external code, and the external code had an exploitable issue. This is fairly uncommon, as most applications avoid using JNI where possible.

It is possible for a method to write into valid entries of an array that it did not intend to, typically through integer overflow.

For instance the following is not sufficient to check bounds:

/* !! WRONG !! */ 0 <= off && 0 <= len && off+len <= buff.length /* !! WRONG !! */

IIRC, StringBuffer once had a bug like that, but there wasn't anything interesting you could do with it.

One of the key features of JAVA is Security. Programs written in interpreted languages are not prone to the buffer overflow exploit, but you can always cause a buffer overflow in Interpreter itself. Although it will be difficult. Similarly Python also is an interpreted language and is safe from buffer overflow.