Oracle Java 7 Update 15, Java 6 Update 41, Java 5.0 Update 40, and earlier versions contain a vulnerability that can allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system.
The Oracle Java Runtime Environment (JRE) 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.
Additional details of the vulnerability can be found at FireEye Malware Intelligence Lab blog post.
This vulnerability is reportedly being exploited in the wild.
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 these vulnerabilities.
Apply an update
These issues are addressed in Java 7 Update 17 and Java 6 Update 43. Please see the Oracle Security Alert for CVE-2013-1493 for more details.
Unless it is absolutely necessary to run Java in web browsers, disable it as described below, even after updating to 7u17. This will help mitigate other Java vulnerabilities that may be discovered in the future.
This issue has also been addressed in IcedTea versions 1.11.9 and 1.12.4.
Disable Java in web browsers
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, 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
.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| Status| Date Notified| Date Updated
Oracle Corporation| | -| 05 Mar 2013
If you are a vendor and your product is affected, let us know.
Group | Score | Vector
Base | 10.0 | AV:N/AC:L/Au:N/C:C/I:C/A:C
Temporal | 8.7 | E:H/RL:OF/RC:C
Environmental | 9.4 | CDP:H/TD:H/CR:ND/IR:ND/AR:ND
Oracle credits the following people or organizations for reporting security vulnerabilities addressed by this Security Alert to Oracle: an Anonymous Reporter of TippingPoint's Zero Day Initiative; axtaxt viaTipping Point's Zero Day Initiative; Darien Kindlund of FireEye; Vitaliy Toropov via iDefense; and Vitaliy Toropov via TippingPoint.
This document was written by Michael Orlando.