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@xxxxxxxxxxxxxxxxxxxxxxxxx> 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
