Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
I'm playing with some generally well written and parsed java code, but there are some oddities thrown up by my code scanning tool.
I know a null pointer dereference can crash a program, but assuming the code is written to catch and manage all exceptions, does anyone know of a real attack that could use this issue?
Code snippets gratefully received :-)
If you try to use pointer that is null, Java will throw a NullPointerException. Since this is a RuntimeException, you don't have to catch it, but you can. So for example
String iAmNull = null;
iAmNull.trim();
will throw a NullPointException and exit the program. If however you catch it
try {
String iAmNull = null;<br>
iAmNull.trim();<br>
} catch (NullPointerException e) {
log.warn("Null pointer in method x")
}
it will continue to run and simply log the error (if you have set up a logger of course). Alternatively, it is also possible to catch Exception e.
Attacks based on null pointers in Java are theoretically impossible, since the Java Virtual Machine handles all pointers, so it shouldn't be a problem if you have a NullPointer in your code.
Theoretically, any kind of null-pointer dereferencing in Java triggers a NullPointerException, which can be handled within Java just as any other exception. This does not mean that this is good: in practice, it is quite hard to recover from such an exception except by removing the faulty part (i.e. letting the calling thread die, or getting back to a catch-all clause). Following a null pointer is akin to overrunning a buffer: it is still a bug; the difference here between Java and non-protected languages (such as C) is that Java is more graceful about the consequences of that bug: in particular, the exception will propagate back the call stack, releasing monitors (the synchronized keywords) and executing the finally clauses, and only the faulty thread will be affected.
In practice, however, a few issues may arise. How the JVM traps null pointer dereferences is up to the JVM implementation; but what implementations usually do is the following: they just follow the pointer. If the pointer is null, then this leads to a memory access in the first page of memory, which is access-forbidden by the OS. The OS catches the occurrence (through the MMU) and informs the application in a relatively brutal way (on Unix-like systems, this is a SIGSEGV signal). The JVM receives the information, and transforms it into a NullPointerException.
The conversion from signal to exception is a complex thing because the JVM only receives the offending opcode address, which is somewhere either in the bytecode interpreter, or in the JIT-produced binary code. The JVM must locate the method and the thread stack. This has some fine interactions with how the OS put things in memory in the first place. Such code is quite stable nowadays, on mainstream platforms. However, on a less common combination (Sun's JDK ported to FreeBSD), I sometimes had null pointer dereferences for which the JVM was unable to locate the caller stack (because the JVM code was tuned for Linux, not for FreeBSD, and was apparently making an assumption on where the stack should be, assumption which was not always fulfilled on FreeBSD). Consequence was immediate JVM termination, in a most ungraceful way.
Another possible gotcha is that the null pointer dereference is caught because the access falls somewhere in a "forbidden" page; namely, the first page of the address space. However, when accessing an instance field, the JVM usually accesses directly the right data element: if the reference is, at native code level, a pointer to address x, and the field is at offset n in the object structure, then the code will read bytes at address x+n (this really depends on how the JVM represents objects internally, but a C-like structure is common). If the class has many fields, then n may be greater than the size of a page, in which case the read access will not fall on the first page, but the second. What happens in that situation depends on the operating system.
The "field at high offset" situation does not arise with arrays, because array accesses are length-checked and the "length" is usually a kind of field which is close to the object header. Also, there is a limit on the number of fields in a Java class (there is an absolute limit to 65535 in the class file format, actually lower than that because each field must have a name and a type, which are also in the class file format and will hit other limits sooner than that). So the problem will not arise on "common" systems, e.g. a Linux running Sun/Oracle VM. This is mostly something that VM implementers must be aware of.
So my advice is to consider NullPointerException as a serious bug, just like a buffer overflow (which is IndexOutOfBoundsException in Java). The VM safety will help you debug your code (stack traces are really handy) and, if you did not debug enough before deploying, it will probably save your skin. But a bug is a bug.
CWE-476: NULL Pointer Dereference - states that code execution is possible in very rare circumstances and environments is possible. However this is not specific to Java. I've check all the exploit websites I can think of to see if any have exploits for Java based on a null pointer deference and haven't been able to find any.
But while looking around I came across this page on the Cert site - EXC15-J. Do not catch NullPointerException. They state that catching the NullPointerException is suboptimal at best and that in lieu of adding checks to avoid the exception is significantly slower. So depending on your application that may be something you want to consider.
Dereferencing any null in Java code will cause an NPE. Unlike C, there is no way to add an offset to land in mapped memory. The NPE will either be caught by a catch or passed through to the thread's uncaught exception handler.
A cause of actual vulnerabilities in Java is accepting nulls where they shouldn't be. Skipping code for null variables is in fact more dangerous than carrying on and NPEing. For instance, ClassLoader references are capabilities, but the most important class loader (the boot class loader) is typically indicated by null (some Java APIs add extra security checks if a supplied class loader reference is null).
