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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ