full-disclosure - [SE-2012-01] One more attack affecting Oracle's Java SE 7u15

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <5134B0D8.4060903@security-explorations.com>
Date: Mon, 04 Mar 2013 15:34:00 +0100
From: Security Explorations <contact@...urity-explorations.com>
To: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk
Subject: [SE-2012-01] One more attack affecting Oracle's
	Java SE 7u15

Hello All,

Last week, Oracle disputed our claim regarding one of the Issues
reported to the company on Feb 25, 2012. This was Issue 54 that
was partly responsible for a successful attack demonstrated in
the environment of Java SE 7 Update 15.

It turns out Oracle's attempt to deny Issue 54 turned out to be
quite fruitful. It made us look into Java SE 7 code and its docs
once again (gathering counterargument material). As a result:
- we confirmed that company's initial judgment of Issue 54 as the
   "allowed behavior" contradicts both Java SE documentation as well
   as existing security checks in code. It looks Oracle needs to
   either start treating Issue 54 as a vulnerability or change the
   docs and relax some of the existing security checks.
- 5 new security issues were discovered in Java SE 7 (numbered 56
   to 60), which when combined together can be successfully used to
   gain a complete Java security sandbox bypass in the environment
   of Java SE 7 Update 15.

Our vulnerability report along with a working Proof of Concept
code was submitted to Oracle today [1].

Two of the issues found (59 and 60) could be potentially affecting
Java SE 6 (we haven't checked this due to Java SE 6 EOL status),
but since all of the issues need to be combined together to gain
a successful Java SE security compromise, we treat it as affecting
Java SE 7 only.

The attack breaks a couple of security checks introduced to Java
SE by Oracle over the recent months (Issues 57 and 58). It also
exploits code fragments that were missing proper security checks
corresponding to the very mirror code (Issue 59 and 60). Finally,
it demonstrates a difference between the JVM specification and
its implementation (Issue 56).

At the end, should we say that the Reflection API is the usual
victim ?

Thank you.

Best Regards
Adam Gowdiak

---------------------------------------------
Security Explorations
http://www.security-explorations.com
"We bring security research to the new level"
---------------------------------------------

References:
[1] SE-2012-01 Vendors status
     http://www.security-explorations.com/en/SE-2012-01-status.html

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/