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 i
    s 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

    Share this post

    Share on facebook
    Share on linkedin
    Share on print
    Share on email

    Subscribe to our Monthly Cyber Security Digest

    Get monthly content to keep you up to date on the latest news and tips