In a result of its research investigation efforts, Security Explorations discovered multiple critical security vulnerabilities in Java Platform, Standard Edition.
This section of our website presents initial information regarding the project that lead to this discovery:
Security Explorations decided to release technical details of Issue 54 that was reported to Oracle on Feb 25, 2013 and that was evaluated (...)
Security Explorations founder and CEO, Adam Gowdiak will give a talk at Devoxx Java Community Conference in Antwerp [1] in Nov 2012 (...)
Java has been within our interest for nearly a decade. We've been breaking it with successes since 2002 and are truly passionate about it. Regardless of the many changes that had occurred in the Rich Internet Application's [1] space, Java is still present in the vast number of desktop computers. According to some published data [2], Java is installed on 1.1 billion desktops and there are 930 million Java Runtime Environment downloads each year. These numbers speak for itself and it's actually hard to ignore Java when it comes to the security of PC computers these days.
Java is one of the most exciting and difficult to break technologies we have ever met with. Contrary to the common belief, it is not so easy to break Java. For a reliable, non memory corruption based exploit codes, usually more than one issue needs to be combined together to achieve a full JVM sandbox compromise. This alone is both challenging and demanding as it usually requires a deep knowledge of a Java VM implementation and the tricks that can be used to break its security.
We are quite experienced when it comes to breaking Java security. We were able to spot a couple of things that were simply missed by Sun Microsystems [3] and/or Oracle. We also came up with some new ideas for the abuse of Java security.
Yes. Discovered security issues violate many "Secure Coding Guidelines for the Java Programming Language" [4]. Additionally, most of them demonstrate a specific problem related to Java SE security. This problem has its origin in certain design / implementation choices made with respect to the security architecture of a Java Virtual Machine.
Sun Microsystems had been aware of these problems since at least 2005. This was the time when we discovered specific attack techniques and reported more than 20+ security issues to the company. The more surprised we were to find so many instances of a known security problem in the latest version of Java SE software.
The most serious issues could lead to the complete compromise of a Java security sandbox. Malicious Java applet or application exploiting one of them could run unrestricted in the context of a target Java process such as a web browser application. An attacker could then install programs, view, change, or delete data with the privileges of a logged-on user.
We verified that as a result of a successful attack, arbitrary files could be created or programs executed in the environment of the affected Java SE software.
In the most common web browser attack scenario, an attacker could host a specially crafted website with a malicious Java application exploiting one of the vulnerabilities found. Upon convincing the user to visit such a website, typically by getting them to click a link in an email or in an Instant Messenger message, malicious web content could be delivered to affected systems.
It could also be possible to display specially crafted web content by using banner advertisements or by using other methods to deliver web content to vulnerable systems.
Java SE vulnerabilities can be exploited on servers if malicious input can be supplied to a vulnerable API or server component.
We have demonstrated such a possibility in the context of Java RMI servers such as RMI Registry from JDK 7 Update 11 and Oracle GlassFish Server 3.1.2.2 (with security manager enabled). Our Proof of Concept code implements a successful attack against RMI services exposed by the abovementioned servers. It also shows that Oracle's evaluation of Java SE vulnerabilities' impact is not necessarily correct (we exploit the flaws that according to the company "can be exploited only through untrusted Java Web Start or Java applets applications" [6]).
As of Feb 05, 2013 attacks through RMI protocol are still valid and in this context remote exploitation of security vulnerabilities in Java SE on servers should be always concerned.
Since 59 of the issues found are pure Java bugs, our Proof of Concept codes are fully reliable and should work with flying colors on any system platform with the affected Oracle Java SE or IBM Java installed. Most of them combine more than one issue together to achieve a complete Java security sandbox compromise.
There is only one vulnerability that can lead to an arbitrary memory corruption condition. We have however come up with an exploitation technique that can be successfully used for that issue to achieve a reliable code execution in a DEP / ASLR environment such as Windows 7 OS.
These are issues 10, 13 and 21. There is also one mitigation in the code that makes our original exploitation scenario for Issue 26 not working anymore.
These are Issues 11 (a part of it related to ClassFinder flaw), 16, 17, 20 and 28. There is also one mitigation in the code that makes our original exploitation scenario for a complete Java security sandbox compromise not working any more.
This issue, when combined with some of our previously reported issues makes it possible again to completely escape Java 7 security sandbox. Recently, we've been also able to verify that this issue alone is sufficient for a complete compromise of Java 7 security.
We verified that these are: Java SE 1.4 (build 1.4.2_13-b06), Java SE 5 Update 22 (build 1.5.0_22-b03), Java SE 6 Update 35 (build 1.6.0_35-b10), Java SE 7 Update 7 (build 1.7.0_07-b10) and Java SE 8 (build 1.8.0-ea-b57).
No. Issues 29 and 50 are not addressed by that CPU. Issue 50 can be used to achieve a complete Java VM security sandbox bypass under Java SE 6 Update 37 and Java SE 7 Update 9. Oracle has communicated to us that both issues will be addressed in Feb 2013.
According to information received from Oracle, this update addresses Issues 29, 50, 52 and 53.
No. As of Mar 05, 2013 eight vulnerabilities (Issues 51, 54-60) remain unpatched. We confirmed that they can be used to achieve a complete Java VM security sandbox bypass under Java SE 7 Update 17 and below.
We discovered one weakness (Issue 22) in the implementation of Java API extensions embedded by Apple Quicktime software. When combined with Issue 15 reported to Oracle on Apr 2 2012, the new Apple Quickitme weakness could be used to successfully bypass all JVM security restrictions on a target system.
The issue in Apple Quicktime for Java has its own story. It's a perfect example illustrating how tricky Java security could be (this is the 4th time we point out to Apple a problem in the implementation of a fix for same security issue).
IBM SDK is an implementation of Java SE technology from IBM corporation. Security issues found in IBM Java also help us illustrate certain problems related to Java security. Thus, a decision to make them part of our SE-2012-01 project (Security Vulnerabilities in Java SE).
The whole research took us 3 months of work in total.
We published the results of this research on 14 November 2012 at Devoxx Java Community Conference [5] in Antwerp, Belgium. We also released a technical report and selected Proof of Concept codes for discovered vulnerabilities. All published materials are available to download from here.
Information about security defects in Java needs to be more open to the public. This will allow for the improvement of Java security in a long term. People will be more aware of the various pitfalls they should avoid and know what to look for during either code development or security review efforts.
No. We decided that SE-2012-01 would be a Pro Bono security research project. This means that all vendors of affected technologies are given information about vulnerabilities in their products completely for free. We also provided all vendors with source code of our Proof of Concept codes illustrating the issues found.
Per our disclosure policy, only original vendors of the affected technology or software are provided with brief vulnerability information.
Last update: Oct-29-2013
Impact characteristics of the Proof of Concept (PoC) codes developed during the research of Java SE security:
This page presents details of security vulnerabilities and attack techniques discovered as a result of our Java SE security research project. These details are provided in a form of a technical report and presentation slides for the talk that was given by Adam Gowdiak on 14 Nov 2012 at Devoxx Java Community Conference in Antwerp.
Additionally, the slides for a keynote talk given at JavaLand conference in 2016 are also provided. This talk referred to SE-2012-01 and our other research projects while discussing key problems related to Java platform security, its ecosystem and vendors.
Proof of Concept Codes below are provided purely for educational purposes only. It is expressly forbidden to use them for any purposes that would violate any domestic or international laws. If you do not agree with this policy, please leave this page.
This page presents current status of the communication process with vendors of affected technologies.