Vulnerability Note VU#636312
Oracle Java JRE 1.7 Expression.execute() and SunToolkit.getField() fail to restrict access to privileged code
Oracle Java Runtime Environment (JRE) 1.7 contains a vulnerability that may allow an applet to call setSecurityManager in a way that allows setting of arbitrary permissions.
The Oracle Java Runtime Environment (JRE) 1.7 allows users to run Java applications in a browser or as standalone programs. Oracle has made the JRE available for multiple operating systems.
The Java JRE plug-in provides its own Security Manager. Typically, a web applet runs with a security manager provided by the browser or Java Web Start plugin. Oracle's document states, "If there is a security manager already installed, this method first calls the security manager's checkPermission method with a RuntimePermission("setSecurityManager") permission to ensure it's safe to replace the existing security manager. This may result in throwing a SecurityException".
This vulnerability is being actively exploited in the wild, and exploit code is publicly available.
By convincing a user to visit a specially crafted HTML document, a remote attacker may be able to execute arbitrary code on a vulnerable system.
Disable Java in web browsers
Disable the Java plug-in and Java Deployment Toolkit for Internet Explorer
Disabling the Java plug-in for Internet Explorer is significantly more complicated than with other browsers. There are multiple ways for a web page to invoke a Java applet, and multiple ways to configure Java Plug-in support. Microsoft has released KB article 2751647, which describes how to disable the Java plug-in for Internet Explorer. However, we have found that due to the multitude of ways that Java can be invoked in Internet Explorer, their guidance (as well as our prior guidance) does not completely disable Java. However, we have provided a registry file that disables all of the CLSIDs provided by Java versions up through Java 7 Update 6, as well as blocks invocation of java through the <applet> element in the IE by setting the URLACTION_JAVA_PERMISSIONS flag for the "Internet Zone." If you wish to disable the <applet> element in other zones, you can modify the registry file to suit your needs. See Microsoft KB article 182569 for more details. In our testing, importing this registry file appears to prevent invocation of Java applets in Internet Explorer.
A registry file that Disables the <applet> element in the IE "Internet Zone", sets the kill bit for all of the Java CLSIDs through Java 7 update 6, the Java Web Start ActiveX control, the Java Deployment Toolkit ActiveX controls, as well as prevents IE from automatically opening JNLP files, as described above, is available for download here:
If you wish to re-enable Java that has been disabled using the above registry file, you can import the following registry file:
Additionally, if you wish to disable the Java Plug-in for Internet Explorer at the plug-in file level, you may also consider the following steps:
Disable "Open 'safe' files after downloading" in Safari
By default, Safari on Mac OS X is configured to automatically open "safe" files after downloading, which also happens automatically. Java JLNP files are considered to be "safe." Disable the option "Open 'safe' files after downloading," as specified in the Securing Your Web Browser document. This will help prevent automatic exploitation of this and other vulnerabilities. Note that Java 7 is not provided with OS X by default, however it is provided by Oracle as an optional download.
Due to the impracticality of disabling Java in Internet Explorer with Java versions prior to 7 Update 10, you may wish to uninstall Java to protect against this vulnerability.
Use different browsers for different activities
An effective way of mitigating risk of web browsing is to use separate browsers for different activities online. For example, if you do online banking, choose a browser to use for banking and nothing else. This can help minimize the risk of a malicious web page being able to interfere with the banking activity. The same concept applies to Java. If you use a web site that requires Java, then choose and configure a browser to have Java enabled, and only access that resource with that browser. Other browsers should have Java disabled, as described above. This helps minimize the exposure of Java to untrusted web sites.
Do not access Java Applets from untrusted sources
Attackers must deliver a malicious Java applet to a vulnerable system in order to take advantage of this vulnerability. This includes opening JNLP files, as Java Web Start can be used to execute a Java applet. By only accessing Java applets from known and trusted sources the chances of exploitation are reduced.
Using the Mozilla Firefox NoScript extension to whitelist web sites that can run scripts and access installed plugins will mitigate this vulnerability. See the NoScript FAQ for more information.
Vendor Information (Learn More)
|Vendor||Status||Date Notified||Date Updated|
|OpenJDK||Affected||-||30 Aug 2012|
|Oracle Corporation||Affected||29 Aug 2012||30 Aug 2012|
|Apple Inc.||Not Affected||-||29 Aug 2012|
|Microsoft Corporation||Not Affected||31 Aug 2012||06 Sep 2012|
CVSS Metrics (Learn More)
This vulnerability was publicly reported by FireEye.
This document was written by Will Dormann, Fred Long, Michael Orlando, and David Svoboda.
- CVE IDs: CVE-2012-4681
- US-CERT Alert: TA12-240A
- Date Public: 26 Aug 2012
- Date First Published: 27 Aug 2012
- Date Last Updated: 16 Jan 2013
- Document Revision: 247
If you have feedback, comments, or additional information about this vulnerability, please send us email.