Bug 906449 - (CVE-2013-1489) CVE-2013-1489 Oracle JDK 7: bypass of the security level setting in browser plugin (Deployment, SE-2012-01 Issue 53)
CVE-2013-1489 Oracle JDK 7: bypass of the security level setting in browser p...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20130127,reported=2...
: Security
Depends On:
Blocks: 906458 906729
  Show dependency treegraph
 
Reported: 2013-01-31 11:28 EST by Jan Lieskovsky
Modified: 2013-02-15 09:33 EST (History)
5 users (show)

See Also:
Fixed In Version: Oracle Java SE 7u13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-05 01:50:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jan Lieskovsky 2013-01-31 11:28:56 EST
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/
Comment 1 Tomas Hoger 2013-01-31 11:50:19 EST
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.
Comment 2 Tomas Hoger 2013-02-01 16:10:01 EST
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
Comment 3 Tomas Hoger 2013-02-04 12:23:10 EST
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
Comment 4 errata-xmlrpc 2013-02-04 18:54:48 EST
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
Comment 6 Tomas Hoger 2013-02-06 03:24:42 EST
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

Note You need to log in before you can comment on or make changes to this bug.