Tag Archive | Java Runtime Environment

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.

Critical Java patch issued for 30 security holes

Oracle has issued a critical advisory for multiple (30) vulnerabilities in Java Runtime Environment. Most of the flaws involve Java Runtime Environment, however a couple of them are issued for JavaFX.

Here is our update table:

Version affected: JRE version 7 update 7 and previous => need update 9 now

Version affected: JRE version 6 update 35 and previous => need update 37 now

Version affected: JRE version 5 update 36 and previous => no patch available!

As always, you can get the latest Java updates from the following methods:

  • WINDOWS = Access Start > Control Panel > Java. Click the Update Tab and select Update Now. (You can also enable automatic updates through this method)
  • Any other method: http://www.java.com – click the Free Java Download. It should auto-detect your system.

NOTE: If you use the offline installer found on java.com, make sure you’re aware that it bundles either Ask Toolbar or McAfee Security Scan Plus. It isn’t recommended to install either one, but that choice is up to you.
Read more about different Java issues:

%d bloggers like this: