Hello All,

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