Think Information. Think Security.
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 aRuntimePermission("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 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.
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. As a solution, apply an update. This issue is addressed in Java 7 Update 7. To protect against future Java vulnerabilities, consider the following workarounds: Disable the Java plug-in.
Disabling the Java browser plugin may prevent a malicious webpage from exploiting this vulnerability.

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, US Cert have found that due to the multitude of ways that Java can be invoked in Internet Explorer, their guidance does not completely disable Java. However, they 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. 

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:

    @="JNLP File"

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, as well as prevents IE from automatically opening JNLP files, as described above, is available for download here:
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
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, you may wish to uninstall Java to protect against this vulnerability. If Java is still needed, consider installing the latest version of Java 6.
After uninstalling Java 7, the Java 6 JRE can be obtained from the Oracle Java download page. The latest Java 6 version as of the publication of this document is Java SE 6 Update 35.

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.

Cross-posted from: US Cert

Leave a Reply.