03:11 AM
Connect Directly

Tech Insight: 5 Approaches To Decaffeinating Java Exploits

Most enterprises might be stuck with Java, but there are ways reduce the effectiveness of recent and future zero-day 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.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
1/29/2013 | 6:51:30 PM
re: Tech Insight: 5 Approaches To Decaffeinating Java Exploits
so, ive blocked them and i feel better.

Am I correct in the fact that all java exploits will come via downlaoded jar or class files?
User Rank: Apprentice
1/24/2013 | 10:03:39 PM
re: Tech Insight: 5 Approaches To Decaffeinating Java Exploits
ive been monitoring all the jar and class files flowing from the internet into our network. There are not many at all. Next week I will block all jar file and class files from the internet.
Andrew Binstock
Andrew Binstock,
User Rank: Apprentice
1/23/2013 | 3:51:19 AM
re: Tech Insight: 5 Approaches To Decaffeinating Java Exploits
For most organizations, #4 is the option that makes the most sense.
User Rank: Strategist
1/23/2013 | 12:33:37 AM
re: Tech Insight: 5 Approaches To Decaffeinating Java Exploits
Wonder how many orgs are stuck with Java due to having apps that require it for financial,
reporting, and other biz solutions...

Kelly Jackson Higgins, Senior Editor
Dark Reading
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2014-07-10
Multiple cross-site scripting (XSS) vulnerabilities in group/control_panel/manage in Liferay Portal 6.1.2 CE GA3, 6.1.X EE, and 6.2.X EE allow remote attackers to inject arbitrary web script or HTML via the (1) _2_firstName, (2) _2_lastName, or (3) _2_middleName parameter.

Published: 2014-07-10
The File Transfer feature in WebEx Meetings Client in Cisco WebEx Meetings Server and WebEx Meeting Center does not verify that a requested file was an offered file, which allows remote attackers to read arbitrary files via a modified request, aka Bug IDs CSCup62442 and CSCup58463.

Published: 2014-07-10
Heap-based buffer overflow in the file-sharing feature in WebEx Meetings Client in Cisco WebEx Meetings Server and WebEx Meeting Center allows remote attackers to execute arbitrary code via crafted data, aka Bug IDs CSCup62463 and CSCup58467.

Published: 2014-07-10
Cross-site scripting (XSS) vulnerability in viewfilecontents.do in the Dialed Number Analyzer (DNA) component in Cisco Unified Communications Manager allows remote attackers to inject arbitrary web script or HTML via an unspecified parameter, aka Bug ID CSCup76308.

Published: 2014-07-10
The Multiple Analyzer in the Dialed Number Analyzer (DNA) component in Cisco Unified Communications Manager allows remote authenticated users to bypass intended upload restrictions via a crafted parameter, aka Bug ID CSCup76297.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.