It was discovered that the Hotspot component in OpenJDK failed to properly check the format of a loaded SharedArchiveFile. If a JVM was instructed to load untrusted SharedArchiveFile, it could cause JVM to execute arbitrary code. OpenJDK versions 6 and 7 only load shared archive that is distributed with JDK and the file path is hard-coded in JVM. OpenJDK 8 allows alternate shared archive file name to be specified using the -XX:SharedArchiveFile= command line option.
Public now via Oracle Critical Patch Update - October 2014. Fixed in Oracle Java SE 8u25. External References: http://www.oracle.com/technetwork/topics/security/cpuoct2014-1972960.html#AppendixJAVA
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2014:1636 https://rhn.redhat.com/errata/RHSA-2014-1636.html
IssueDescription: It was discovered that the Hotspot component in OpenJDK failed to properly handle malformed Shared Archive files. A local attacker able to modify a Shared Archive file used by a virtual machine of a different user could possibly use this flaw to escalate their privileges.
Upstream OpenJDK commits: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/d4b48e12a10f http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/ca6d25be853b
The Oracle October 2014 CPU was updated to use the following note for this issue: Applies to client and server deployment of Java. This vulnerability requires local access to the victim environment in order to plant the affected jar file. Once the affected jar file was planted, this vulnerability can be triggered through sandboxed Java Web Start applications, sandboxed Java applets, and launching the affected application locally. It can also be triggered by supplying data to APIs in the specified component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.