We discovered yet another indication that new Reflection API introduced into Java SE 7 was not a subject to a thorough security review (if any). A new vulnerability (Issue 69) that was submitted to Oracle today makes it possible to implement a very classic attack against Java VM. What's in particular interesting is that the attack itself has been in the public knowledge for at least 10+ years [1]. It's one of those risks one should protect against in the first place when new features are added to Java at the core VM level. The more surprising it is to discover that Reflection API introduced to Java SE 7 didn’t implement proper protection against this attack. Our Proof of Concept code for Issue 69 was confirmed to work with flying colors under Java SE 7 Update 25 (1.7.0_25-b16) and below. The code allows to violate a fundamental feature of Java VM security - the safety of its type system. As a result, a complete and reliable Java security sandbox bypass can be gained on a vulnerable instance of Oracle's Java SE software. Oracle's blog post published on May 30, 2013 [2] implies that maintaining the security-worthiness of Java has been Oracle’s priority following the acquisition of Sun Microsystems. Oracle's VP goes even further by indicating that "acquired product lines [such as Java SE] were required to conform to Oracle policies and procedures, including those comprising Oracle Software Security Assurance" [3]. If Oracle had any Software Security Assurance procedures adopted for Java SE, most of simple Reflection API flaws along with a known, 10+ years old attack should have been eliminated prior to Java SE 7 release. This didn't happen, thus it is reasonable to assume that Oracle's security policies and procedures are either not worth much or their implementation is far from perfect. That thought alone should catch attention of Oracle customers not necessarily relying on Java SE, but rather on other Oracle products, which were likely the subject to the very same, questionable Software Security Assurance policies and procedures as Java SE 7. -- As for other things, we released technical details and Proof of Concept code for a previously reported security vulnerability (Issue 61) that got fixed by Oracle's Java SE CPU in Jun 2013: http://www.security-explorations.com/materials/SE-2012-01-ORACLE-12.pdf http://www.security-explorations.com/materials/se-2012-01-61.zip We also released technical details and Proof of Concept codes for several (9 in total) IBM Java flaws that were addressed by the company in early Jul 2013: http://www.security-explorations.com/materials/SE-2012-01-IBM-2.pdf http://www.security-explorations.com/materials/se-2012-01-62-68.zip The above includes details of trivially broken fixes for vulnerabilities reported to IBM in Sep 2012 (Issues 35-37 and 49). One of the issues is also a nice illustration of the "allowed behavior" (Issue 54) for other than Oracle's Java VM implementations. Finally, we published information (and some comment) about CVE numbers assigned by Oracle to vulnerabilities reported by Security Explorations as part of SE-2012-01 project: http://www.security-explorations.com/materials/SE-2012-01-CVE_Map.pdf Thank you. Best Regards Adam Gowdiak --------------------------------------------- Security Explorations http://www.security-explorations.com "We bring security research to the new level" --------------------------------------------- References: [1] Java and Java VM security vulnerabilities and their exploitation techniques, Last Stage of Delirium Research Group, http://lsd-pl.net/ [2] Maintaining the security-worthiness of Java is Oracle’s priority https://blogs.oracle.com/security/entry/maintaining_the_security_worthiness_of [3] Oracle Software Security Assurance http://www.oracle.com/us/support/assurance/overview/index.html