Java patched at least 4 bugs

The last couple of days there has been a big convulsion on the social networks about the Java zero days found in a Chinese attack campaign on the Internet.

After some deep analysis of the Jar used in the exploit, we found out that there were actually two bugs exploited in order to jump outside the Java security sandbox.

Oracle has just released a new update, Java JDK/JRE 7 update 7 is now
available at
http://www.oracle.com/technetwork/java/javase/downloads/index.html

The release notes say that this contains fixes for CVE-2012-4681. This seems to be a new move in the recent history of Java updates, since generally it takes months to QA a Java security bug fix - which may be how long this took, considering some researchers claim they sent these vulnerabilities to Oracle months ago.

While doing some fast analysis (keep in mind we only spent an hour and half on it), we find out that they patched at least 4 vulnerabilities in the Java code base: The two used by the Gondvv worm and two more on difference pieces of code. Just by simply running the Immunity CANVAS exploit that exploits this vulnerability we can see that this update is preventing it.

When we run the exploit we get the following exception:

java.security.AccessControlException: access denied
("java.lang.RuntimePermission" "accessClassInPackage.sun.awt")
 at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:366)
 at
java.security.AccessController.checkPermission(AccessController.java:555)
 at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
 at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1529)
 at sun.applet.AppletSecurity.checkPackageAccess(AppletSecurity.java:283)
 at sun.reflect.misc.ReflectUtil.checkPackageAccess(ReflectUtil.java:134)
 at com.sun.beans.finder.ClassFinder.findClass(ClassFinder.java:100)
 at com.sun.beans.finder.ClassFinder.resolveClass(ClassFinder.java:170)
 at java.beans.Statement.invokeInternal(Statement.java:213)
 at java.beans.Statement.access$000(Statement.java:58)
 at java.beans.Statement$2.run(Statement.java:185)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.beans.Statement.invoke(Statement.java:182)
 at java.beans.Expression.execute(Expression.java:121)
 at Gondvv.GetClass(Gondvv.java:38)
 at Gondvv.SetField(Gondvv.java:46)
 at Gondvv.disableSecurity(Gondvv.java:30)
 at Gondvv.init(Gondvv.java:53)
 at sun.applet.AppletPanel.run(AppletPanel.java:434)
 at java.lang.Thread.run(Thread.java:722)


There isn't much information in the traceback about the exact changes that this update includes so taking a better look we can see that not only these 2 vulnerabilities used in the Gondvv exploit have been patched, but also some others.

The two vulnerabilities used in the exploit were located in com.sun.beans.finder.ClassFinder and com.sun.beans.finder.MethodFinder

The update also patched at least another 2 other vulnerabilities that were basically the same but related to Constructors and Fields and allowed an attacker to get any public constructor or any public field via reflection bypassing security checks. 

These 2 vulnerabilities were located in com.sun.beans.finder.ConstructorFinder and com.sun.beans.finder.FieldFinder and the underlying issue was the same "a trusted immedate caller".

These two "new" vulnerabilities patched combined with the MethodFinder weakness could allow you to bypass the Sandbox and obtain full execution on Linux, Windows and MacOSX.  Now Oracle has added proper checks by adding calls to methods of sun.reflect.misc.ReflectUtil class.

Another interesting change this update includes is that public static methods getField and getMethod in sun.awt.SunToolkit were removed which means that the technique used in the exploit to get a private field no longer works.

- Esteban Guillardoy

  @sagar38