Tuesday, August 28, 2012

Are you vulnerable to the latest Java 0-day exploit? (Updated)

Test to see if you're vulnerable.

You may be aware that a 0-day vulnerability in the latest version of Java is presently being exploited on the Web. This vulnerability affects all versions of Java 1.7 (aka Java 7). Oracle has not yet released a fix and if they stick to their quarterly patch cycle, one isn't likely to emerge until October.

Java has a long history of 0-day vulnerabilities being actively exploited. Exploits are usually drive-by attacks: users get infected by navigating to hijacked websites where an invisible Java applet drops a malicious executable on the user's machine. The very popular, Blackhole exploit kit includes numerous Java exploits.

In 2010, we reported a 300% increase of malicious JAR (Java archive) files. Recently, in March 2012, Java made the news due to the Flashback Trojan, a piece malware targeting an older Java version that shipped with Mac OS X. As can be seen, Java is constantly under attack.

Update: new Java version available

Oracle has released java 1.7.7 and 1.6.35 to fix the vulnerability. You can update your java version from Java.com.

We have updated our Java test page to take the new versions into account.

Are you vulnerable?

The latest iteration of Java is version 1.7 revision 6. This is now the default version on Windows. Mac OS X still uses Java 1.6 (latest version: 1.6.33). Java 1.6.33 is NOT vulnerable to the latest 0-day exploit. However, I would not suggest that anybody downgrade from Java 1.7 to Java 1.6 as it is not yet known if version 1.6 is vulnerable to other flaws fixed in 1.7.

One annoying fact with Java is that new versions are installed on top of each other. As such, you are likely to have multiple versions of Java installed on your system. Internet Explorer may not even be using the latest version of Java that you have installed.

We have created a new page to list all of the versions of Java installed on your computer. You can test your browser here.

Disable Java

To be on the safe side, you can disable Java in your browser to prevent malicious applets from running.

Firefox

Go to Tools - Add-ons - Plugins

Look for Java Deployment Toolkit and/or Java Platform SE. Disable them all.

Java disabled in Firefox

Chrome

Go to WrenchSettings and Show advanced settings... - Privacy and Content settings - Plug-ins - Disable individual plug-ins... - Java - disable. It is quite difficult to find!

Java enabled in Chrome

Internet Explorer

Go to Tools - Manage Add-ons. Disable Java(tm) Plug-in SSV Helper and Java(tm) Plug-in 2 SSV Helper.


Java disabled in Internet Explorer 9
Update: To completely disable Java in Internet Explorer, follow the steps at http://www.kb.cert.org/vuls/id/636312#disable_java_in_IE.


Test it

Now go to our Java test page (updated) to ensure that Java has indeed been disabled in your browser.

Click to Play

If you need Java occasionally, you can enable it on-demand with Click to Play. I described Click to Play, a way to manually enable plugins only on visible content, in a previous post. This feature is only available in Firefox, Chrome and Opera.

Firefox also offers several browser extensions to easily enable/disable java with one click. I personally like Quick Java.

Take this opportunity to check all the plugins running in your browser and disable the plugins that you do not really need. Don't give the bad guys an attack surface that's any larger than it needs to be!

11 comments:

Anonymous said...

http://zulu.zscaler.com/research/java_version.html

First of all thanks for this free test. I have only one problem. I am an Opera user and have already disabled the java plug-in in the browser. Nevertheless this test page here still detects my Java version number and says that the vulnerability still persists.

Oracle's own Java test page says that my plug-in is disabled just as a number of other test sites. How to explain this? Do I have to worry?

Anonymous said...

Some want to write up a how-to downgrade Java 7 to 6....

It's not as easy as it sounds....

Anonymous said...

Thanks for the free test ;-) come back clean (zero )

Art said...

We found that disabling the Java Plug-in in IE was more complicated than just using the Manage Add-ons. Furthermore disabling the the "SSV" add-ons doesn't disable the Java Plug-in. More info here: http://www.kb.cert.org/vuls/id/636312#disable_java_in_IE

Julien Sobrier said...

I have a updated the test page to differentiate between Java being installed, and Java being enabled in the browser.

Julien Sobrier said...

Art: you're right, it looks like the add-ons disable the bridge JavaScript<->Java only. JavaScrit detects that Java is disabled, but applets are actually executed. I have updated the post with the link you provided. Thank you

Anonymous said...

The vulnerable version of JRE should be preinstalled and if target host had been compromised by running a malicious java applet then there should be evidence of compromise right? There is need for some kind of payload to be executed on client side: 'C:\WINDOWS\system32\calc.exe' for example.

Anonymous said...

The vulnerable version of JRE should be preinstalled and if target host had been compromised by running a malicious java applet then there should be evidence of compromise right? There is need for some kind of payload to be executed on client side: 'C:\WINDOWS\system32\calc.exe' for example.

Anonymous said...

It would be awesome if Zscaler had a report to show which users/websites are loading Java applets. That report could then in turn, be used to create a whitelist of sites to allow Java either directly inside of Zscaler (best since browser doesn't matter then) or through Group Policy (difficult if multiple browsers are in use).

Art said...

To follow up on my previous comment, we've since found our advice to disable Java in IE still came up short. There's an update now (Java 7u7), and we've updated our advice at http://www.kb.cert.org/vuls/id/636312#disable_java_in_IE

XPGoD said...

Oddly, Java 7 Update 11 was JUST applied to my machine via manual means, and your page still states it's vulnerable. The version shows as 1.7.0 on your page, but shows as 1.7.0_11 in my machine... is there an update to this???