I am not intimately familiar with Java, so this could be a stupid question.

In a C program I can find buffer overflows or may be a ROP based exploit to run custom code. How is it done in the context of Java? Is it even possible? In Java strings or other data types are all bounded and so overwriting memory is not possible. What about ROP kind of attacks?

Or more generically what are the typical attack vectors for a Java program?

  • Since Java does a lot with automated garbage collecting, there are some funky thinks you can do to memory with Java objects. Heap spraying, use-after-frees, etc are possible. Unfortunately I'm not a Java expert. – RoraΖ Sep 9 '14 at 19:54
  • 2
    Thanks to the VMs memory abstraction, most of the techniques which are typical exploits of badly written C code can rarely be found in Java. – Philipp Sep 9 '14 at 20:28
  • So much I guessed. So how are exploits done in Java? – user220201 Sep 9 '14 at 20:33
  • I think this should be kept open as it can be reasonably answered in a few paragraphs. – paj28 Sep 11 '14 at 10:38
  • As it is "how are exploits done in Java" is very broad. I'd suggest closing if it's staying as is. If the scope were to be narrowed to "how can I identify X-type exploits in Java", it might be more appropriate for the StackExchange format. I suggest expanding just a bit on your C programming experience, then asking about comparable methods in Java (e.g.: "In C, I'd look for buffer overflows or ROP based exploits like this... how do I do the same thing in Java?"), and completely nuking the last sentence - perhaps even nuke everything starting with "Is it even possible". – Iszi Sep 11 '14 at 17:45

You would be very lucky to find a case where you can directly execute code via a simple coding error in Java. It is possible that a bug in the implementation of the JVM allows memory corruption through benign code, but at worst phenomenally rare.

However, even within the JRE (OpenJDK) a portion of the libraries are written in C, and therefore contain memory corruption vulnerabilities when used with untrusted data. Rendering a malicious JPEG would be the canonical example.

There are lots of non-memory related bugs, such as injection (HTML, SQL, LDAP, HTTP headers, etc), but those in general wont lead you directly to remote code execution.

A far too common situation is where a handy library deliberately executes remote code without deliberate being enabled by the application programmer. Examples given in Secure Coding Guidelines for Java SE (5.0) Guideline 3-8 / INJECT-8: Take care interpreting untrusted code are certain feature in: the scripting API, LiveConnect, XSLT extensions, Long Term Persistence of JavaBeans Components, Java Sound, RMI, LDAP and certain JDBC/SQL implementations. An application may deliberately load mobile code, which leads to a whole other world.


One option is exploiting the JVM itself - it may be possible to have java code that causes the actual virtual machine to 'break' and execute arbitrary operations outside of the sandbox; there have been such exploits, although they seem to rely on sending the victim some java code for execution (i.e., in a browser sandbox context), not exploiting random java programs.

Another option is to identify and abuse logic problems in the programs. In C exploits, a typical scenario is to use a bad boundary check as a way to obtain totally undefined behavior (such as execution of arbitrary code) unrelated to the particular check; however in absence of that, some bad boundary checks or logic problems may achieve a code path that (unintentionally) is in the original code and does what you want.

And of course all the joys of multi-layer app complexity have possible attack vectors - SQL injections if that java app links to a database, etc.


The short answer would be "all the rest of them", but not including the simplistic kinds of errors from exploiting raw memory buffer overflows. There are plenty of other ways that memory could be used incorrectly without overrunning a buffer.

An example something that might be classified as a buffer overflow problem in java would be if the application used try/catch to intercept attempted buffer overflows, and as a result of catching one, bypassed some important code. You could imagine a badly written "checkpassword" function that ended up returning "success" if given a password with too many characters.


Common Java security flaws include:

  • Injection attacks - SQL injection, cross-site scripting, XPath injection, XML external entity, and many more. I'm aware of about 20 different kinds of injection.
  • Business logic flaws - Parameter tampering, forced browsing, negative numbers accepted, etc.
  • Authentication and session flaws - No account lockouts, session fixation, predictable session ID, etc.
  • Others - Information leakage, executable file upload, etc.

The flaws I just mentioned apply to Java applications themselves. A common scenario is a Java web application, which can be attacked by malicious web clients. Even if the JVM itself is 100% secure, applications can have their own weaknesses.

Another scenario is Java applets. This is actually a very different situation, an untrusted Java applet is running in your browser, within a sandbox, and it is attempting to break out of the sandbox. Here the security of the JVM itself is crucial.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.