Exploitable Java functions

Question

This question is similar to Exploitable PHP Functions.

Tainted data comes from the user, or more specifically an attacker. When a tainted variable reaches a sink function, then you have a vulnerability. For instance a function that executes a sql query is a sink, and GET/POST variables are sources of taint.

What are all of the sink functions in the Java class library (for any flavor of Java)? I am looking for functions that introduce a vulnerability or software weakness. I am particularly interested in Remote Code Execution vulnerabilities. Are there whole classes/libraries that contain nasty functionally that a hacker would like to influence? How do people accidentally make dangerous Java code?

Answer 1

Here's a list based on my personal research into Client-side Java security in general, and using the Eclipse IDE to see which methods do SecurityManager checks.

ClassLoaders define classes (=arbitrary java code execution):

java.lang.ClassLoader.defineClass
java.net.URLClassLoader

= code execution

Java Beans Introspection may divert ClassLoaders into loading classes from an untrusted source (example vuln - cve-2010-1622)

java.beans.Instrospector.getBeanInfo

= code execution

File access

java.io.File (constructor)
java.io.File.delete
java.io.File.renameTo
java.io.File.listFiles
java.io.File.list

= deleting/renaming files, directory listing

File stream/reader classes

java.io.FileInputStream
java.io.FileOutputStream
java.io.FileReader
java.io.FileWriter
java.io.RandomAccessFile

=File read/write access

Java System Properties

System.setProperty
System.getProperties
System.getProperty

=Some system properties might contain some information that's almost sensitive, and some system properties might alter the execution of critical stuff, I don't have examples, though

Loading native libraries

System.load
System.loadLibrary

= Arbitrary code execution

Executing operating system executables

Runtime.exec
ProcessBuilder (constructor)

Generating native system input events

java.awt.Robot.keyPress/keyRelease
java.awt.Robot.mouseMove/mousePress/mouseRelease

(Maybe far-fetched since a server might not even have a graphical environment)

Java reflection - accessing arbitrary (even private) fields and methods

java.lang.Class.getDeclaredMethod
java.lang.Class.getDeclaredField
java.lang.reflection.Method.invoke
java.lang.reflection.Field.set
java.lang.reflection.Field.get

= From disclosing sensitive information to eventual code execution, depending on the circumstances

Java scripting engine

javax.script.ScriptEngine.eval

=arbitrary code execution

Answer 2

Code execution vulnerabilities:

1. Private reflection, but it's uncommon for tainted data to get there in a dangerous way
2. Native interop code which doesn't validate it's parameters enough
3. De-serializers. Probably the most dangerous since you might want to de-serialize from untrusted data. Some serializers are relatively safe and only use public constructors/setter, but others access private fields. And if there is no type white-list it might instantiate arbitrary types and call setters on them.
4. Any form of IO, files in particular
5. Dynamic loading of libraries. In particular using relative path. In particular relative to the working-directory instead of the executable directory

(This is about .net, but I expect Java to be very similar)

Data injection

Then there is the injection family of functions which typically can be prevented by not operating on strings but using specialized library functions. Those typically don't lead to arbitrary code injection.

1. html injectiong / XSS (Largely prevented by a view-engine that auto-escapes output and cleanly separating escaped and un-escaped strings (perhaps using different types))
2. SQL injection (prevented by prepared statements)
3. File-Path injection

Answer 3

I am sure that this list will grow as I dig into finding real exploits:

1. Spring classloader

2. Swallowed exceptions - As has been noted swallowing exceptions may not directly cause an exploitation, but it can lead to the non-discovery of exploitation.

3. String[] commands = {args[0]};
Runtime.getRuntime().exec(commands);
   I realize that it is a fairly trivial item, but running code similar to the above can allow you to pass something like this: && del / if on Windows or ;rm -rf / on *nix

The biggest way people make dangerous Java code is by being lazy. As you mentioned not cleansing user input before running it.