Message-ID: <503CC632.4070205@security-explorations.com>
Date: Tue, 28 Aug 2012 15:22:58 +0200
From: Security Explorations <contact@...urity-explorations.com>
To: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk
Subject: [SE-2012-01] information regarding recently discovered Java 7 attack


Hello All,

This post is made in reference to recently discovered attack against
Java SE 7 platform [1][2]. We discovered that the vulnerabilities used
by the attack code are similar to some of the weaknesses that we have
found as part of our SE-2012-01 Java SE security research project [3].

The recently reported Java attack relies on a couple of issues, which
are briefly described below.

[Vuln 1]
    The first vulnerability stems from the fact that it is possible
    to obtain references to restricted classes such as those coming
    from a sun.* package.

    The weakness has its origin in com.sun.beans.finder.ClassFinder
    class and its findClass method. The bug is caused by insecure
    usage of reflective forName call of java.lang.Class class.

    We reported what seems to be an instance of Vuln 1 to Oracle in Apr
    2012 (Issue 11). In our report describing Issue 11 we demonstrated
    a successful loading of a "sun.awt.SunToolkit" class by the means
    of a findClass method of ClassFinder class. We however did associate
    this behavior with a slightly different cause.

[Vuln 2]
    The second vulnerability relies on the possibility to obtain
    references to methods of restricted classes. It has its origin
    in findMethod method of com.sun.beans.finder.MethodFinder class.
    The bug is caused by insecure usage of reflective getMethod call
    of java.lang.Class class.

    Vuln 2 was reported to Oracle in Apr 2012 (Issue 16).

    Insecure ClassFinder and MethodFinder classes were introduced in
    Java 7. Among other things, this has lead to the modification of
    java.beans.Statement class implementation. Java 6 implementation
    of the aforementioned class seems to be more secure as it relies
    on a ReflectionUtils class introduced at the time of fixing the
    vulnerabilities reported to Sun Microsystems back in 2005 [4].

[Exploit vector]
    The exploit vector for the reported code relies on sun.awt.Suntoolkit
    class and the ability to call its getField method. This method allows
    to obtain privileged (with override field set to true) references to
    private fields of arbitrary classes (including restricted ones).

    Exploit vector relying on sun.awt.SunToolkit class and its getField
    method was reported to Oracle in Apr 2012. We demonstrated full JVM
    sandbox bypass by abusing SunToolkit class implementation, but in
    a different way than it is done in a circulating code. Again, Java 6
    implementation of SunToolkit class seems to be more secure as its
    getField method is defined to be private (it is public in Java 7).

The reported attack code will not work in Java 6 environment for the
reasons described above. Although, Java 7 adoption might not be high
yet, with the release of Java SE 7 Update 4, Java SE 7 runtime is the
default JRE [5].

On 23 Aug 2012, Oracle provided us with a monthly status report for
the security issues reported to the company earlier this year. The
company informed us that 19 of the remaining 25 issues were fixed in
main codeline and that they are scheduled for a future CPU. This
include fixes for some of the issues (11 and 16) that are used by
the attack code recently revealed.

We plan to release a short technical paper presenting the results of
our Java SE security research after Oracle releases their next Java
SE CPU (scheduled for Oct 2012) and most serious issues get fixed.

Thank you.

Best Regards,
Adam Gowdiak

---------------------------------------------
Security Explorations
http://www.security-explorations.com
"We bring security research to the new level"
---------------------------------------------

References:
[1] Zero-Day Season is Not Over Yet
 
http://blog.fireeye.com/research/2012/08/zero-day-season-is-not-over-yet.html#more
[2] Let's start the week with a new Java 0-day in Metasploit
 
https://community.rapid7.com/community/metasploit/blog/2012/08/27/lets-start-the-week-with-a-new-java-0day
[3] SE-2012-01 Security vulnerabilities in Java SE
     http://www.security-explorations.com/en/SE-2012-01.html
[4] Sun Alert 200688
     http://download.oracle.com/sunalerts/1000543.1.html
[5] Moving to Java 7 as default
     https://blogs.oracle.com/henrik/entry/moving_to_java_7_as

Powered by blists - more mailing lists