Tech Insight: 5 Approaches To Decaffeinating Java Exploits

The recent zero-day exploit for Java left enterprises scrambling to protect their networks from the active exploits out in the wild. The effectiveness of the exploit, its active use by exploit kits like Blackhole, and a window of time with no patch meant no one was safe -- at least not anyone who hadn't already taken steps to neuter Java by uninstalling or uncoupling it from their Web browsers.

Unfortunately, much misinformation has been published on what uses Java, which of those things are threatened by this exploit, and how to protect against the exploit. Before we focus on how to protect against the current (and future) Java exploits, let's quickly address the first two items.

First, Java is not JavaScript, but it does provide a cross-platform programming language that allows developers to write Java applets that run within a user's Web browser on different operating systems.

Second, it is this Java interface within Web browsers that exposes the vulnerable Java Runtime Environment (JRE) to malicious Java applets -- and not the server-side Java apps -- hat is vulnerable. If you want to know more about those two items, then take a look at Brian Krebs' piece, "What You Need to Know About the Java Exploit."

With those two items out of the way, let's dig into the top five ways to protect against the recent Java exploit, plus future Java zero-day exploits we'll likely see in the coming weeks and months.

1. Install Java 7 Update 11
Originally, this item was listed as "Do Nothing," but I didn't want to give the wrong impression. Installing the latest version prevents the recent zero-day exploit and requires users to explicitly acknowledge and allow unsigned Java applets to run each time. That's more that "doing nothing," though it does not do much in the way of mitigating future exploits. It's not like an attacker could ever steal a company's code-signing certificate that could be used to sign malicious Java applet.

2. Uninstall Java
This is highly effective ... for everyone except businesses that require Java for financial, reporting, and other types of business software built on Java. For example, does your company use any Oracle Forms Applications, firewall, and/or network management tools written in Java or some Cisco business products that leverage Java? If so, then this option isn't for you; you're stuck with Java indefinitely.

3. Allowing Java Only In Restricted Virtual Machines
Virtualization is one approach that can be used to provide a sandbox on the desktops of users that require Java for particular types of applications. Java could be completely uninstalled from users' workstations yet allowed to run inside of a virtual machine on those same workstations. Similar configurations have been used to isolate sensitive applications to be run from only virtual machines, so why not do the same for Java?

To tighten the security further, the Web browsers and network traffic from the virtual machine could be restricted to lists of predefined servers and Web applications, limiting the likelihood that casual browsing from the virtual machine could lead to compromise. And if Java were exploited through a Web browser in the virtual machine, the virtual machine could easily be reverted to a previous state or deleted and redeployed to its original state.

4. Decouple Java From The Web Browser
Removing Java from the Web browser is one of the more effective methods to keep Java on the desktop while mitigating the zero-day's method of attack. It is also likely to have the least impact on enterprise environments since the majority of enterprise Java applications are standalone applications. These applications run within the Java Runtime Environment and are not Java applets running within a Web browser.

With the release of Java 7 Update 10, Oracle has included the ability to easily decouple Java from the Web browser. Details on how to do this are located here: "Oracle: How do I disable Java in my Web browser?"

5. Use Separate Web Browsers -- And Only One with Java Enabled
This option is similar to No. 4 where Java is disabled within the Web browser. The difference is that this approach allows for more than one Web browser (i.e., Internet Explorer, Google Chrome, Firefox) to be installed on workstations, but only one has Java enabled in it. One browser can be used for daily Web browsing, another browser for more sensitive transactions, and maybe a third browser that has Java enabled and used only for websites that require Java.

The difficulty with this last approach is that it requires user training on which browser is appropriate for the task being performed. Technical controls can be put in place to prevent users from using a particular Web browser for the wrong task. The browsers could be configured to the security level that fits with their purpose. Proxy servers can define that limit with which sites the Web browsers can communicate.

Is this last approach practical? It depends on the organization, whether some of these controls are already in place, and if the number of Java applications being used is worth the time and effort required to implement the controls.

[The continued waves of Java zero-days have security experts recommending that enterprises re-evaluate how they use Java. See The Death Of Java In The Enterprise?]

Before deciding on one of the methods above, first take an inventory of which applications require Java, the users and/or groups that use those applications, and where Java is currently installed. Having that data in hand will help make choosing an option much easier.

Have a comment on this story? Please click "Add a Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.