Serious Java Vulnerabilities Have Many Things in Common (mini-whitepaper)

If you’ve seen many of our posts here, you’d know that we report about Java vulnerabilities. As often as they come, they must have something in common, right? Indeed.

Let’s discover the vulnerabilities of CVE-2012-4681 and CVE-2012-5076, what’s similar and what we can learn about these two serious vulnerabilities. These use a Java reflection mechanism that breaks applet security restrictions, and allow a malicious payload. In other words, they bypass security and execute malicious code.

Now, Java reflection is used in programs commonly, usually those requiring the examination of runtime behavior of applications running in Java Virtual Machine. It is very convenient for Java developers (despite saving time) to write Java programs, but it also opens up more opportunities for exploits.

Now, to open up for the technical part, which you can skip if you don’t understand Java or it would give you a headache. 🙂

== TECHNICAL START ==

Java reflection has many functions and they are:

  1. GET class
  2. GET all members and methods in class include private ones
  3. Invoke methods

Java’s big vulnerability in dealing with reflection is that it allows hidden fields. Obviously, this isn’t a true flaw (meaning the Java developers don’t see a problem), but it would help to change this attribute to avoid further problems.

Now, CVE-2012-4681 used Java reflection to induce a hidden field that was called statement.acc. It implemented, also, the “setfield” function, which changes the value of the ACC file (found in the hidden field).  To break the code, “Java.beans.statement” would be implemented.

So, in Java, we’d see:

SetField(Statement.class, "acc", localStatement, localAccessControlContext);

Then, as we analyze CVE-2012-5062, we see the big offender, “util. GenericContructor”, which is used to create an object from a restricted class. We would implement it like “sun.invoke.anon.AnonymousClassLoader”, and then call its function “loadclass” – that would deliver the malicious payload. Here is a breakdown of how the payload would work:

  1. GET the method “loadclass” and then invoke.
  2. GET the method “r” in payload and then invoke.
  3. Using “Class.forName” to load a target class
  4. Using “getDeclaredFields”, which would enumerate all fields (not including hidden ones).
  5. Using “setAccessible” to expose hidden/private fields.
== TECHNICAL END ==

Obviously, it’s time, researchers, to keep an eye on Java reflection vulnerabilities.

Advertisements

Tags: , , , ,

About Jay Pfoutz

Marketer
%d bloggers like this: