What are common Java vulnerabilities?

Question

What are common Java vulnerabilities that can be exploited to gain some sort of access to a system? I have been thinking about it recently, and havent been able to come up with much of anything - integer overflow - maybe? race condition - what does it give you?

I am not looking for things like "sql injection in a web app". I am looking for a relationship similar to buffer overflow - c/c++.

Any security experts out there that can help out? Thanks.

Answer 1

I'm not a security expert, but there are some modules in our company that we can't code in java because it is so easy to de-compile java bytecode. We looked at obfuscation but if you want real obfuscation it comes only with a lot of problems (performance hit/loss of debug information).
One could steal our logics, replace the module with a modified version that will return incorrect results etc...

So compared to C/C++, I guess this is one "vulnerability" that stands out.

We also have a software license mechanism built-in in our java modules, but this can also be easily hacked by de-compiling and modifying the code.

Answer 2

Including third party class files and calling upon them basically means you are running unsecure code. That code can do anything it wants if you don't have security turned on.

Answer 3

Malicious Code injection.

Because Java (or any language using an interpreter at runtime), performs linkage at runtime, it is possible to replace the expected JARs (the equivalent of DLLs and SOs) with malicious ones at runtime.

This is a vulnerability, which is combated since the first release of Java, using various mechanisms.

• There are protections in places in the classloaders to ensure that java.* classes cannot be loaded from outside rt.jar (the runtime jar).
• Additionally, security policies can be put in place to ensure that classes loaded from different sources are restricted to performing only a certain set of actions - the most obvious example is that of applets. Applets are constrained by the Java security policy model from reading or writing the file system etc; signed applets can request for certain permissions.
• JARs can also be signed, and these signatures can be verified at runtime when they're loaded.
• Packages can also be sealed to ensure that they come from the same codesource. This prevents an attacker from placing classes into your package, but capable of performing 'malicious' operations.

If you want to know why all of this is important, imagine a JDBC driver injected into the classpath that is capable of transmitting all SQL statements and their results to a remote third party. Well, I assume you get the picture now.