Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


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
A Startup With NSA Roots Wants Silently Disarming Cyberattacks on the Wire to Become the Norm
Kelly Jackson Higgins, Executive Editor at Dark Reading,  5/11/2021
Cybersecurity: What Is Truly Essential?
Joshua Goldfarb, Director of Product Management at F5,  5/12/2021
3 Cybersecurity Myths to Bust
Etay Maor, Sr. Director Security Strategy at Cato Networks,  5/11/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Google Maps is taking "interactive" to a whole new level!
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-05-17
Cross Site Scripting (XSS) in emlog v6.0.0 allows remote attackers to execute arbitrary code by adding a crafted script as a link to a new blog post.
PUBLISHED: 2021-05-17
Cross Site Request Forgery (CSRF) in Pluck CMS v4.7.9 allows remote attackers to execute arbitrary code and delete a specific article via the component " /admin.php?action=page."
PUBLISHED: 2021-05-17
Cross Site Request Forgery (CSRF) in Pluck CMS v4.7.9 allows remote attackers to execute arbitrary code and delete specific images via the component " /admin.php?action=images."
PUBLISHED: 2021-05-17
A heap based buffer overflow vulnerability exists in GNU LibreDWG 0.10 via read_2004_section_handles ../../src/decode.c:2637.
PUBLISHED: 2021-05-17
A heap based buffer overflow vulnerability exists in GNU LibreDWG 0.10 via read_2004_section_revhistory ../../src/decode.c:3051.