bugtraq - [SE-2012-01] Broken security fix in Oracle Java SE 7/8/9

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 for Android: free password hash cracker in your pocket

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

Message-ID: <56E117CE.4010109@security-explorations.com>
Date: Thu, 10 Mar 2016 07:44:30 +0100
From: Security Explorations <contact@...urity-explorations.com>
To: bugtraq@...urityfocus.com, fulldisclosure@...lists.org
Subject: [SE-2012-01] Broken security fix in Oracle Java SE 7/8/9

Hello All,

On Mar 07, 2016 Security Explorations modified its Disclosure Policy [1].
As a result, we do not tolerate broken fixes any more. If an instance
of a broken fix for a vulnerability we already reported to the vendor
is encountered, it gets disclosed by us without any prior notice.

The vendor that gets the questionable honor to be the first to experience
our modified Disclosure Policy is Oracle.

Yesterday, during my JavaLand talk [2], while discussing the problems
related to Java platform security, its ecosystem and vendors I disclosed
general information about a broken Oracle Java SE fix from Sep 2013:

http://www.security-explorations.com/materials/se-javaland.pdf

This was the fix for the last vulnerability we reported to the company
as part of our Java SE security research (Issue 69 [3]). This weakness
made it possible to implement a very classic attack against JVM (class
spoofing attack).

According to Oracle, the vulnerability was addressed by a backported
(from JDK 8) implementation of the affected component (method handles
API) in JDK 7 Update 40 from Sep 2013.

We however found out that Oracle patch could be trivially bypassed with
the use of the following:
- four character change to our original POC code published in Oct 2013,
- a custom HTTP server enforcing "404 (Not Found)" error when requesting
   a given class for the first time.

Full technical details of Oracle fix bypass can be found in our technical
report:

http://www.security-explorations.com/materials/SE-2012-01-ORACLE-14.pdf

Along with the report, we have also published a Proof of Concept code to
illustrate the broken fix:

http://www.security-explorations.com/materials/se-2012-01-69.2.zip

The POC was successfully verified in the environment of Java SE 7 Update
97, Java SE 8 Update 74 and Java SE 9 Early Access Build 108. A complete
Java security escape could be achieved with it.

Please, note that the published material neither constitutes the bypass
of Java security levels, nor its Click2Play functionality. It's a mere
Java security sandbox escape.

At the end, it's worth to note that beside breaking a fix for Issue 69
(CVE-2013-5838), Oracle also improperly evaluated its impact. Oracle
Critical Patch Update from Oct 2013 indicated that Issue 69 could "be
exploited only through sandboxed Java Web Start applications and sandboxed
Java applets". This is not true. We verified that it could be successfully
exploited in a server environment as well such as Google App Engine for
Java [4].

Thank you.

-- 
Best Regards,
Adam Gowdiak

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

References:
[1] Disclosure Policy
     http://www.security-explorations.com/en/disclosure-policy.html
[2] JavaLand conference, "Java (in)security" talk
     http://www.javaland.eu/en/javaland-2016/
[3] SE-2012-01-ORACLE-13, Issue 69
     http://www.security-explorations.com/materials/SE-2012-01-ORACLE-13.pdf
[4] SE-2014-02, Issue21 (POC23)
     http://www.security-explorations.com/materials/se-2014-02-32-34.zip