Common Vulnerabilities and Exposures assigned an identifier CVE-2013-1489 to the following vulnerability: Unspecified vulnerability in Oracle Java SE 7 Update 10 and Update 11 (JRE 1.7.0_11-b21) and possibly other versions, when running on Windows using Internet Explorer, Firefox, Opera, and Google Chrome, allows remote attackers to bypass the "Very High" security level of the Java Control Panel and execute unsigned Java code without prompting the user via unknown vectors, aka "Issue 53." NOTE: as of 20130130, this vulnerability does not contain any independently-verifiable details, and there is no vendor acknowledgement. A CVE identifier is being assigned because this vulnerability is receiving significant public attention, and the original researcher has an established history of releasing vulnerability reports that have been fixed by vendors. References: [1] http://seclists.org/fulldisclosure/2013/Jan/241 [2] http://blogs.computerworld.com/malware-and-vulnerabilities/21693/yet-another-java-security-flaw-discovered-number-53 [3] http://thenextweb.com/insider/2013/01/28/new-vulnerability-bypasses-oracles-attempt-to-stop-malware-drive-by-downloads-via-java-applets/ [4] http://www.scmagazine.com.au/News/330453,java-still-unsafe-new-flaws-discovered.aspx [5] http://www.zdnet.com/java-update-doesnt-prevent-silent-exploits-at-all-7000010422/
Security Level setting was introduced in Oracle Java SE 7 Update 10: http://www.oracle.com/technetwork/java/javase/7u10-relnotes-1880995.html http://www.java.com/en/download/help/jcp_security.xml http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/client-security.html This can not affect OpenJDK, which does not include browser plugin. IcedTea-Web plugin for OpenJDK does not currently offer similar security feature. Additionally, according to the limited information in the public report, this problem is about bypassing Security Level protection, and it is not a Java sandbox restriction. Hence this needs to be combined with other flaw to achieve code execution.
This issue is now fixed in Oracle Java SE 7 Update 13, including the following note: This issue (CVE-2013-1489) has been discussed publicly and is sometimes known as the "Java Security Slider vulnerability". It has a CVSS of 0 because it does not directly result in an exploitation, but may be combined with other vulnerabilities to allow blind exploitation. When the Security Slider is set to the default (high) all unsigned applets must be authorized via a dialog box by a browser user in order to execute. This provides the browser operator the opportunity to prevent execution of suspicious applets that may result in successful exploits. However, when CVE-2013-1489 is combined with vulnerabilities that can be used to cause direct impacts, the effect can be that the impact can be caused "silently" without the authorization dialog box. External Reference: http://www.oracle.com/technetwork/topics/security/javacpufeb2013-1841061.html
Additional details from Adam Gowdiak of Security Explorations: http://seclists.org/fulldisclosure/2013/Feb/12 [Issue 53] Issue 53 stems from the fact that Oracle's implementation of new security levels introduced by the company in Java SE 7 Update 10 did not take into account the fact that Applets can be instantiated with the use of serialization. Such a possibility is indicated both in HTML 4 Specification [5] as well as in Oracle's code. HTML 4 Specification contains the following description for the "object" attribute of APPLET element: object = cdata [CS] This attribute names a resource containing a serialized representation of an applet's state. It is interpreted relative to the applet's codebase. The serialized data contains the applet's class name but not the implementation. The class name is used to retrieve the implementation from a class file or archive. Additionally, Java 7 Update 10 (and 11) reveal the following code logic when it comes to the implementation of new security features (Java Control Panel security levels). [excerpt from sun.plugin2.applet.Plugin2Manager class] String object_attr = getSerializedObject(); String code_attr = getCode(); ... if(code_attr != null) { Class class1 = plugin2classloader.loadCode(code_attr); ... if(class1 != null) if (fireAppletSSVValidation()) ... } else { if(!isSecureVM) return; adapter.instantiateSerialApplet(plugin2classloader,object_attr); ... } The above clearly shows that the conditional block implementing Applet instantiation via deserialization does not contain a call to fireAppletSSVValidation method. This method conducts important security checks corresponding to security levels configured by Java Control Panel. The lack of a call to security checking method is equivalent to "no protection at all" as it allows for a silent Java exploit in particular. What's worth mentioning is that for Google Chrome the following HTML sequence needed to be used to activate target Applet code: <object type="application/x-java-applet" object="BlackBox.ser"> [5] HTML 4 Specification, Including an applet: the APPLET element http://www.w3.org/TR/html401/struct/objects.html#h-13.4 Original report: http://www.security-explorations.com/materials/SE-2012-01-ORACLE-9.pdf
This issue has been addressed in following products: Supplementary for Red Hat Enterprise Linux 5 Supplementary for Red Hat Enterprise Linux 6 Via RHSA-2013:0237 https://rhn.redhat.com/errata/RHSA-2013-0237.html
Nico Waisman's (Immunity) blog post detailing this issue, with the same finding as posted by Adam Gowdiak (comment 3): http://immunityproducts.blogspot.com/2013/02/keep-calm-and-run-this-applet.html