Digital satellite TV platform

Back to research

{ FAQ }

  • Why did you look into desktop Java security?

    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.

  • Is it easy to break Java security?

    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.

  • How is it possible that you were able to find so many bugs in latest Java 7?

    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.

  • Is there anything specific about discovered vulnerabilities?

    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.

  • What is the impact of the issues found?

    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.

  • How could these issues be exploited?

    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.

  • Is it also possible to exploit Java SE vulnerabilities on servers?

    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 (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.

  • How reliable are your Proof of Concept codes?

    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.

  • Which issues are being addressed by Oracle's Java Critical Patch Update from Jun 12, 2012?

    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.

  • Which issues are being addressed by Oracle's Security Alert for CVE-2012-4681 from Aug 30, 2012?

    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.

  • What's the impact of Issue 32 discovered shortly after Java SE 7 Update 7 was released?

    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.

  • Which Java SE versions are affected by Issue 50 reported to Oracle on Sep 25, 2012?

    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).

  • Is Java SE Critical Patch Update from Oct 16, 2012 closing all of the vulnerabilities you reported to Oracle?

    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.

  • Which issues are being addressed by Oracle's Java SE Critical Patch Update from Feb 01, 2013?

    According to information received from Oracle, this update addresses Issues 29, 50, 52 and 53.

  • Is Oracle's Security Alert for CVE-2013-1493 from Mar 04, 2013 closing any of the vulnerabilities you reported to Oracle?

    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.

  • What about the issue in Apple Quicktime for Java?

    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).

  • What's the reason behind including findings in IBM Java as part of the SE-2012-01 project?

    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).

  • How long did you work on this project?

    The whole research took us 3 months of work in total.

  • Do you plan to release more technical information about the issues uncovered?

    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.

  • Do you plan to include this research in your Vulnerability Research Program?

    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.

  • References: