Security Explorations security and vulnerability research company reported: [1] http://seclists.org/bugtraq/2012/Sep/109 presence of a new security flaw, affecting recent Oracle Java SE 5 Update 22, Oracle Java SE 6 Update 35, and Oracle Java SE 7 Update 7 versions of Oracle Java SE software. This flaw is reported to allow complete Java security sandbox bypass. References: [2] http://www.security-explorations.com/en/SE-2012-01.html
According to the vendor communication time line published at: http://www.security-explorations.com/en/SE-2012-01-status.html this issue is not planned to be fixed in the Java CPU to be published today and is only planned to get fixed in the following CPU in Feb 2013. 10-Oct-2012 - Oracle informs that the company is targeting to address Issue 50 in the February 2013 Java SE Critical Patch Update. ... 15-Oct-2012 - Security Explorations asks Oracle about the reason behind company's decision to wait with a patch for a critical Java security issue (number 50) till Feb 2013.
This should be CVE-2013-1475 of the February 2013 Java CPU. 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 50] Issue 50 allows to violate a fundamental security constraint of Java VM, which is type safety. This vulnerability is another instance of the problem related to the unsafe deserialization implemented by com.sun.corba.se.impl.io.ObjectStreamClass class. Its first instance was fixed by Oracle in Oct 2011 [2] and it stemmed from the fact that during deserialization insufficient type checks were done with respect to object references that were written to target object instance created by the means of deserialization. Such a reference writing was accomplished with the use of a native functionality of sun.corba.Bridge class. The problem that we found back in Sep 2012 was very similar to the first one. It was located in the same code (class) and was also exploiting direct writing of object references to memory with the use of putObject method. While the first type confusion issue allowed to write object references of incompatible types to correct field offsets, Issue 50 relied on the possibility to write object references of incompatible types to...invalid field offsets. It might be also worth to mention that Issue 50 was found to be present in Java SE Embedded [3]. That is Java version that is based on desktop Java SE and is used in today’s most powerful embedded systems such as aircraft and medical systems [4]. We verified that Oracle Java SE Embedded ver. 7 Update 6 from 10 Aug 2012 for ARM / Linux contained vulnerable implementation of ObjectStreamClass class. Unfortunately, we don't know any details regarding the impact of Issue 50 in the embedded space (which embedded systems are vulnerable to it, whether any feasible attack vectors exist, etc.). So, it's up to Oracle to clarify any potential concerns in that area. Original report: http://www.security-explorations.com/materials/SE-2012-01-ORACLE-6.pdf http://www.security-explorations.com/materials/SE-2012-01-ORACLE-7.pdf
Upstream commit, as included in IcedTea7 repositories: http://icedtea.classpath.org/hg/release/icedtea7-forest-2.3/corba/rev/127e4c348a71
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
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:0236 https://rhn.redhat.com/errata/RHSA-2013-0236.html
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2013:0246 https://rhn.redhat.com/errata/RHSA-2013-0246.html
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Red Hat Enterprise Linux 6 Via RHSA-2013:0247 https://rhn.redhat.com/errata/RHSA-2013-0247.html
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2013:0245 https://rhn.redhat.com/errata/RHSA-2013-0245.html
Fixed in upstream IcedTea versions IcedTea6 1.11.6, and 1.12.1, and IcedTea7 2.1.5, 2.2.5, and 2.3.6: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2013-February/021708.html http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2013-February/021728.html http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2013-February/021905.html http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2013-February/021876.html Note that version 2.3.5 was tagged in upstream mercurial including the security fixes, but was not released. Only 2.3.6 was released, correcting problem introduced by security patches as included in 2.3.5.
[I'm changing the public= date in the metadata to the date the details were disclosed; prior to 2013-02-01 the existence of the issue was known but without any details until the Oracle update was released.]