Tweet

With Java going through another embarrassing zero-day vulnerability recently, it has become a common bit of advice for users to “uninstall Java”.

In general, this is sound advice. If possible, users should uninstall Java if they don’t need it. Unfortunately, for many users this simply isn’t an option. Many enterprises have custom apps built on the Java platform. Consumers may also need access to Java for banking sites (many of which are Java-based) or software (Minecraft needs Java to run.)

So, how can you use Java safely? First, the Java threat largely comes from malicious applets that come from malicious websites. If you have Java installed because an application needs it, then you can disable Java in your browser(s) without affecting your user experience.

It used to be that you would have to do this on a browser-by-browser basis, but that isn’t the case anymore. In the current version of Java, you can do this in the Java Control Panel. Instructions on how to access this can be found here. Applets in webpages will no longer work, but Java apps will continue to run without any problems.

What if you need Java for a website, like an internal company site or your bank?

In that case, you will have to disable Java on a per-browser basis. Pick a “secondary” browser to use for sites that use Java and disable it in your preferred browser. For example, if you’re a Chrome user, you can use Firefox or Internet Explorer for Java websites. My colleague Rik Ferguson has already posted an entry before that enumerates  steps on how to disable Java depending on the user’s choice of web browser.

Internet Explorer and Firefox both make disabling add-ons easily available from their menus. Chrome hides this somewhat; the best way to reach this setting is to type chrome://plugins in the address bar. Once you’ve reached this setting, disable the Java plug-in to prevent any applets from running in that browser.

Also, another option for Chrome users is to control when an applet is allowed to run or not. Chrome displays a prompt before running Java applets and gives you a choice to run it ‘only this time’ and ‘always run for this site’. Users should ‘run once’ for the sites that they really know would require Java.

To its credit, Oracle is trying to improve the security of Java. The current version – Java 7 Update 11 – raises the default security settings to High, such that unsigned or self-signed Java applets will no longer run without a user prompt. In theory, this should reduce the impact of malicious applets. However, because users can still expressly authorize these malicious applets users may still be affected. (Years of social engineering attacks should have made it clear that users can be induced to click on anything.) Also, there may be cases where the custom applets of enterprises don’t meet this criteria either – leading to the setting being changed.

Still, it’s a good idea to minimize the risk from Java as much as you can. If you can remove the risk completely by removing Java, that would be ideal. If that is not an option for some reason or another, these tips should help you reduce that risk as much as possible.

For information on the protection Trend Micro provides in relation to this threat, you can check our past entry, Java Zero-Day Exploit and Ruby on Rails Vulnerabilities.

Update as of Feb. 3, 10:29 PM PST

Oracle has released updates (Java 7 Update 13) to address several Java vulnerabilities and to resolve a vulnerability used in a reported successful attack in the wild. Users are strongly advised to update their systems with this batch of security updates. More information can be found here.