[<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
Powered by blists - more mailing lists