CVE-2012-4681 Java 7 0-Day vulnerability analysis

Update Aug.30, 2012
Oracle issued update 7 (7u7), which  fixed the vulnerability. 

Update: Aug. 28, 2012.  Rapid 7 / Metasploit released their module  and  we get a lot of  questions related to it from people who wish to compare.  See below the original exploit source, to be run from the command line with a security manager enabled, and it will print the contents of the C:\ root directory.  

ladyilonwick.wordpress.com

Considering that Rapid 7 posted a working exploit and addition to the exploit packs is imminent (Attackers Pounce on Zero-Day Java Exploit by Brian Krebs), plus other analysis articles are being published such as New Java 0day exploited in the wild  -by Alienvault, we decided that witholding details of the exploit will not offer additional protection but only hinder development of protection and signatures.

As we mentioned earlier, we contacted Michael Schierl, the Java expert who discovered a number of Java vulnerabilities and asked him to have a look. He sent back his detailed analysis, exploit source, the interim patch with the source code of the patched class.

Update: Aug. 28, 2012. 
CVE-2012-4681
Oracle Java 7 Update 6, and possibly other versions, allows remote attackers to execute arbitrary code via a crafted applet, as exploited in the wild in August 2012 using Gondzz.class and Gondvv.class.

Patch request:  

At this point the patch is by request is not to preserve the code but limit it to IT administrators and developers who can test and decide if they want to deploy. We do not want to push/offer it to 3 billion end java users, it wasn't tested in all the possible scenarios and systems.

• Interim patch with the source code of the patched class. See the Readme of the patch in the previous post (thanks to Michael Schierl).  

Email from your company email address to admin <at> deependresearch.org   

Additionally, you can request:

• Commented and stripped-down version of the exploit source, to be run from the command line with a security manager enabled, and it will print the contents of the C:\ root directory (thanks to Michael Schierl)

• Original 0-day attack HTML page with javascript, Java applet, downloaded Poison Ivy RAT, and pcap.

Email from your company email address to admin <at> deependresearch.org  and explain the planned use, please.

Analysis 

The Gondvv class decompiles cleanly, and that contained all the
interesting parts.
The real vulnerability seems to be inside the new Java7 class
com.sun.beans.finder.ClassFinder,

http://www.docjar.com/docs/api/com/sun/beans/finder/ClassFinder.html

which seems to make it possible for untrusted code to get access to
classes in restricted packages (i. e. packages that are part of the
security implementation itself and where usually untrusted code cannot
get either access or call it).
At the beginning, the exploit uses that ClassFinder class to get a
reference to the sun.awt.SunToolkit class (sun.* is a restricted package).

http://www.docjar.com/docs/api/sun/awt/SunToolkit.html

The rest of the exploit is "only" using that reference to call the
GetField method, which can be used to get access to private fields
(which should not be a problem as the class is in a restricted package),
to get access to a field that stores the permissions for running a
java.beans.Statement.

http://www.docjar.com/html/api/sun/awt/SunToolkit.java.html#301

A Statement is created that disables the security manager (by default
with permissions of the untrusted code). But before calling the
statement, the permissions stored in that field we just got access to
are overwritten with permissions that allow running all code, and the
statement can be called now and disable the security manager for us. At
this point, no security manager is left, and the applet can do anything
Java can.

This method of abusing restricted package permissions is new to me (it
does not work in Java 6 either as GetField was private there); but it is
not unique - there are several ways you can use to get out of the
sandbox if you have access to restricted packages - usually they need a
bit more code though.

What makes the code a bit more complex is the fact, that the bytecode
verifier also tries to verify if you are accessing restricted packages,
therefore all access to restricted packages has to be done indirectly
(that is also good for obfuscation, but here needed to make the exploit
work, too).  ~ Michael Schierl

Update: Aug 28, 2012
Download it 

by Michael Schierl

Read Part I  Java 7 0-Day vulnerability information and mitigation.

More details :
Aug. 28 More detailed analysis > "Immunity. Java 0day analysis (CVE-2012-4681) by Esteban"
Aug. 28 Java 0-Day Using Latest Dadong’s JS Obfuscator by Kahu Security
Aug. 28 US CERT: We are currently unaware of a practical solution to this problem. Disable Java in your browser

CLICK HERE TO SEE IF YOU ARE VULNERABLE (Zscaler) 

The Zscaler tool checks the version of Java used by your browser. If it is below 1.7_7, you need to update it from Java.com. If it is 1.7_ 7 already, you are safe (for now). As of Aug 31, 2012, the Zscaler checker prints "vulnerable for 0-day" for a ALL versions above 1.6, they just need to update the tool. In reality, if you have the latest version of Java, you are not vulnerable to this exploit.
In general, you don't need Java plug-ins in browser, best to keep it turned off. You can still use Java desktop apps.


Andre' M. DiMino and Mila Parkour