BugTraq
[SE-2012-01] information regarding recently discovered Java 7 attack Aug 28 2012 01:22PM
Security Explorations (contact security-explorations com) (2 replies)
[SE-2012-01] New security issue affecting Java SE 7 Update 7 Aug 31 2012 10:07AM
Security Explorations (contact security-explorations com)
Re: [Full-disclosure] [SE-2012-01] information regarding recently discovered Java 7 attack Aug 29 2012 04:10PM
Jeffrey Walton (noloader gmail com) (1 replies)
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 (at) security-explorations (dot) com [email concealed]> 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-s
tart-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

[ reply ]
Re: [SE-2012-01] information regarding recently discovered Java 7 attack Aug 29 2012 06:40PM
Security Explorations (contact security-explorations com)


 

Privacy Statement
Copyright 2010, SecurityFocus