Vulnerability Note VU#625617
Java 7 fails to restrict access to privileged code
Java 7 Update 10 and earlier versions of Java 7 contain a vulnerability that can allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system.
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. OpenJDK is an open-source implementation of the Java platform, and the IcedTea project aims to make it easier to deploy OpenJDK, including a web browser plugin.
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".
By leveraging the a vulnerability in the Java Management Extensions (JMX) MBean components, unprivileged Java code can access restricted classes. By using that vulnerability in conjunction with a second vulnerability involving recursive use of the Reflection API via the invokeWithArguments method of the MethodHandle class, an untrusted Java applet can escalate its privileges by calling the the setSecurityManager() function to allow full privileges, without requiring code signing. Oracle Java 7 update 10 and earlier Java 7 versions are affected. OpenJDK 7, and subsequently IcedTea, are also affected. The invokeWithArguments method was introduced with Java 7, so therefore Java 6 is not affected.
This vulnerability is being attacked in the wild, and is reported to be incorporated into exploit kits. Exploit code for this vulnerability is also publicly available. We have confirmed that Oracle Java 7 installed on Windows, OS X, and Linux platforms are affected. Other platforms that use Oracle Java 7 may also be affected.
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. Note that applications that use the Internet Explorer web content rendering components, such as Microsoft Office or Windows Desktop Search, may also be used as an attack vector for this vulnerability.
Apply an update
Oracle Security Alert CVE-2013-0422 states that Java 7 Update 11 addresses this (CVE-2013-0422) and an equally severe, but distinct vulnerability (CVE-2012-3174). Immunity has indicated that only the reflection vulnerability has been fixed and that the JMX MBean vulnerability remains. Java 7u11 sets the default Java security settings to "High" so that users will be prompted before running unsigned or self-signed Java applets.
Unless it is absolutely necessary to run Java in web browsers, disable it as described below, even after updating to 7u11. This will help mitigate other Java vulnerabilities that may be discovered in the future.
This issue has also been addressed in IcedTea versions 2.1.4, 2.2.4, and 2.3.4.
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.
Note: Due to what appears to potentially be a bug in the Java installer, the Java Control Panel applet may be missing on some Windows systems. In such cases, the Java Control Panel applet may be launched by finding and executing javacpl.exe manually. This file is likely to be found in C:\Program Files\Java\jre7\bin or C:\Program Files (x86)\Java\jre7\bin.
Also note that we have encountered situations on Windows where Java will crash if it has been disabled in the web browser as described above and then subsequently re-enabled. Depending on the browser used, this Michael Horowitz has pointed out that performing the same steps on Windows 7 will result in unsigned Java applets executing without prompting in Internet Explorer, despite what the "Security Level" slider in the Java Control panel applet is configured to use. We have confirmed this behavior with Internet Explorer on both Windows 7 and Vista. Reinstalling Java appears to correct both of these situations.
System administrators wishing to deploy Java 7 Update 10 or later with the "Enable Java content in the browser" feature disabled can invoke the Java installer with the WEB_JAVA=0 command-line option. More details are available in the Java documentation.
Alternatively, Microsoft has released a Fix it that disables Java in the Internet Explorer web browser.
Restrict access to Java applets
Network administrators unable to disable Java in web browsers may be able to help mitigate this and other Java vulnerabilities by restricting access to Java applets. This may be accomplished by using proxy server rules, for example. Blocking or whitelisting web requests to .jar and .class files can help to prevent Java from being used by untrusted sources. Filtering requests that contain a Java User-Agent header may also be effective. For example, this technique can be used in environments where Java is required on the local intranet. The proxy can be configured to allow Java requests locally, but block them when the destination is a site on the internet.
Vendor Information (Learn More)
If you are a vendor and your product is affected, let
|Vendor||Status||Date Notified||Date Updated|
|IcedTea||Affected||-||16 Jan 2013|
|OpenJDK||Affected||-||14 Jan 2013|
|Oracle Corporation||Affected||11 Jan 2013||13 Jan 2013|
|Red Hat, Inc.||Affected||-||17 Jan 2013|
|Sun Microsystems, Inc.||Affected||11 Jan 2013||12 Jan 2013|
|IBM Corporation||Not Affected||14 Jan 2013||14 Jan 2013|
Thanks to Kafeine for reporting this vulnerability.
This document was written by Will Dormann.
10 Jan 2013
Date First Published:
10 Jan 2013
Date Last Updated:
12 Jun 2013
If you have feedback, comments, or additional information about this vulnerability, please send us email.