lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 29 Aug 2012 12:10:07 -0400
From: Jeffrey Walton <>
To: Security Explorations <>
Subject: Re: [Full-disclosure] [SE-2012-01] information regarding recently
 discovered Java 7 attack


> 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?


On Tue, Aug 28, 2012 at 9:22 AM, Security Explorations
<> 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
> "We bring security research to the new level"
> ---------------------------------------------
> References:
> [1] Zero-Day Season is Not Over Yet
> [2] Let's start the week with a new Java 0-day in Metasploit
> [3] SE-2012-01 Security vulnerabilities in Java SE
> [4] Sun Alert 200688
> [5] Moving to Java 7 as default

Powered by blists - more mailing lists