Message-ID: <CAH8yC8n_8nG4vqYXZAhNw46_mp7ROQgK4xcLRX3-omQAynWiow@mail.gmail.com>
Date: Wed, 29 Aug 2012 12:10:07 -0400
From: Jeffrey Walton <noloader@...il.com>
To: Security Explorations <contact@...urity-explorations.com>
Cc: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk
Subject: Re: [Full-disclosure] [SE-2012-01] information regarding recently
 discovered Java 7 attack

Hi,

> found as part of our SE-2012-01 Java SE security research project [3].
Well, it seems Oracle did not feel the issues Security Explorations
shared were a priority. Blogging about these things has not produced
optimal results either.

Have you reported the issues to US Cert?

Will you be disclosing details on Bugtraq/Full Disclosure?

Jeff

On Tue, Aug 28, 2012 at 9:22 AM, Security Explorations
<contact@...urity-explorations.com> wrote:
>
> 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