Bug 906449 (CVE-2013-1489)

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