Vulnerability Note VU#636312

Oracle Java JRE 1.7 Expression.execute() and SunToolkit.getField() fail to restrict access to privileged code

Original Release date: 27 Aug 2012 | Last revised: 16 Jan 2013

Overview

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.

Description

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".

Oracle Java 1.7 provides an execute() method for Expression objects, which can use reflection to bypass restrictions to the sun.awt.SunToolkit getField() function, which operates inside of a doPrivileged block. The getField() function also uses the reflection method setAccessible() to make the field accessible, even if it were protected or private.

By leveraging the public, privileged getField() function, an untrusted Java applet can escalate its privileges by calling the the setSecurityManager() function to allow full privileges, without requiring code signing. Both the Oracle JRE 1.7 and the OpenJDK JRE 1.7 are affected.

This vulnerability occurred as the result of failing to comply with the following CERT Oracle Secure Coding Standard for Java rules:

  • SEC00-J. Do not allow privileged blocks to leak sensitive information across a trust boundary
  • SEC05-J. Do not use reflection to increase accessibility of classes, methods, or fields

This vulnerability is being actively exploited in the wild, and exploit code is publicly available.

Impact

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.

Solution

Apply an update

This issue is addressed in Java 7 Update 7. To protect against future Java vulnerabilities, consider the following workarounds:

Disable Java in web browsers

Starting with Java 7 Update 10, it is possible to disable Java content in web browsers through the Java control panel applet. Please see the Java documentation for more details. If you are unable to upgrade to Java 7 Update 10 or later, please consider the following workarounds:

Disable the Java plug-in and Java Deployment Toolkit

Disabling the Java browser plug-in and Java Deployment Toolkit plug-in may prevent a malicious webpage from exploiting this vulnerability.

  • Apple Safari: How to disable the Java web plug-in in Safari
  • Firefox: How to turn off Java applets. Make sure to disable both the Java plug-in and the Java Deployment Toolkit plug-in.
  • Chrome: See the "Disable specific plug-ins" section of the Chrome documentation for how to disable Java in Chrome. By default, Chrome will group plug-ins, so clicking "disable" for Java will disable both the Java plug-in and the Java Deployment Toolkit plug-in. However, if you click "Details" to expand the display of plug-ins, be sure to disable both the Java plug-in and the Java Deployment Toolkit plug-ins.
  • Opera: Configure plug-ins to only execute on demand by selecting Opera -> Settings -> Preferences... -> Advanced -> Enable plug-ins only on demand
  • Internet Explorer: See the following section.

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.

Prevent Internet Explorer from automatically opening JNLP files

Java Web Start is a technology for launching Java applications and applets from a web browser. Aside from being invoked from the Java Web Start ActiveX control, Java Web Start can be launched by opening a JNLP file. The Java installer for Windows configures Internet Explorer to automatically open JNLP files without prompting the user. This behavior can be reverted to the safer option of prompting the user by importing the following as a .REG file:

    [HKEY_CLASSES_ROOT\JNLPFile]
    @="JNLP File"
    "EditFlags"=hex:00,00,00,00

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:
Disable_JRE7u6_plugin_webstart_toolkit_and_JNLP_IE.regDisable_JRE7u6_plugin_webstart_toolkit_and_JNLP_IE.reg

If you wish to re-enable Java that has been disabled using the above registry file, you can import the following registry file:
Enable_JRE7u6_plugin_webstart_and_toolkit_IE.regEnable_JRE7u6_plugin_webstart_and_toolkit_IE.reg

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:
  • Remove the next-generation Java plug-in file

    The next-generation Java plug-in is a newer version of the Java plug-in that execute outside the process space of the web browser. Note that this means that when invoked via the next-generation Java plug-in, Java executes outside any restrictions of the browser, such as DEP, Protected Mode, or other sandboxing. The next-generation Java plug-in can be disabled by removing any instance of the jp2iexp.dll file. Common locations for this file on the Windows platform include:
    C:\Program Files\Java\jdk{version}\jre\bin
    C:\Program Files\Java\jre7\bin
    C:\Program Files\Oracle\JavaFX {version} Runtime\bin
  • Remove the Java plug-in file

    If the next-generation Java plug-in option is disabled, Internet Explorer will use the traditional Java plug-in, which operates within the process space of the browser. The Java plug-in can be disabled by removing any instance of the npjpi{version}.dll file. For example, Java 7 Update 6 provides npjpi170_06.dll. Common locations for this file on the Windows platform include:
    C:\Program Files\Java\jdk{version}\jre\bin
    C:\Program Files\Java\jre7\bin
    C:\Program Files\Oracle\JavaFX {version} Runtime\bin

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.

Uninstall Java

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.

Use NoScript

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)

VendorStatusDate NotifiedDate Updated
OpenJDKAffected-30 Aug 2012
Oracle CorporationAffected29 Aug 201230 Aug 2012
Apple Inc.Not Affected-29 Aug 2012
Microsoft CorporationNot Affected31 Aug 201206 Sep 2012
If you are a vendor and your product is affected, let us know.

CVSS Metrics (Learn More)

Group Score Vector
Base 10.0 AV:N/AC:L/Au:N/C:C/I:C/A:C
Temporal 9.5 E:H/RL:W/RC:C
Environmental 9.5 CDP:MH/TD:H/CR:ND/IR:ND/AR:ND

References

Credit

This vulnerability was publicly reported by FireEye.

This document was written by Will Dormann, Fred Long, Michael Orlando, and David Svoboda.

Other Information

  • 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

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.