Plugging Java’s Holes - Is There a Practical Fix?

Developers love Java. But its security problems have gotten out of hand. Is there a practical fix?

IT departments are in a tight spot with Java. The pervasive development language comes with serious security risks, yet many business apps still rely on Java to function. Java ushered in a world of write-once/run-anywhere productivity for developers. Developers need only write their application and let the client-side VM handle all of the cross-platform interoperability. For developers, either commercial or in-house, this continues to provide resounding leverage.

Where it began as a client-server environment, Java has become tightly integrated with the browser, enabling rich applications to be installed and launched by clicking a web link. This transition from client-server to Web-based was driven by the release of the browser plug-in and the "Web Start" functionality in the Java environment. This integration pushed the proliferation of Java apps, but it has also exposed corporate data to attack. Its architecture, which allows links to invoke the plug in and access resources on the user's machine, means that an exploited Java environment can access literally any data on the machine or on your network.

Computer exploits are a numbers game, and attackers focus on the largest population, which is why attacks on the Java browser plug-in continue to grow. Stats to back this up are as close as your security vendor's website. There’s no perfect solution, yet the following ideas are proven ways to get a handle on Java and protect your organization from undue risk and loss.

A few ways to handle Java’s security risks

1. Get rid of Java

To address this noxious problem, one common recommendation is to un-install Java. That may be fine for some users, but it isn't broadly applicable given the number of apps that rely on it. More importantly, running a Java app locally isn't any more or less risky than running an app written in another language. The security exposure relates to the tight linkages between the Java browser plug-in and the local Java environment. If you're willing to subject your users to a little manual work, you may be able to shut off the Java browser plug-in, but still allow Java apps.

First, you’ve got to determine which apps actually require Java, which can be tricky. For example, many popular shared meeting applications don't require the Java plug-in (or even Java) to execute. But to download, launch and join the right meeting they rely on an in-browser Java process. If the plug-in is disabled, clicking a meeting or a link won’t execute for the user. In order to join meetings without the plug-in, users need to launch the native app, manually enter credentials and supply the right meeting ID: it’s a decent workaround but it’s not exactly convenient.

While the manual approach may work for many apps, some still require the Java browser plug-in. One major vendor's popular time tracking app is written in Java with a UI that renders in the browser. To function, both the plug-in and the Java environment need to be running. This means users are n a pretty insecure state. So what can IT do when they must run the Java browser plug-in (or other vulnerable plugins) while managing the risks?

2. Isolate Java

You should remove Java where you don't need it, but where you do, dedicate a standalone computer as "the Java machine". While costly and inconvenient, it minimizes the footprint of Java and allows you to remediate, manage updates and more, in one place. If isolating a machine is impractical, isolate the browser. Dedicate a separate browser on each user’s machine for Java apps. This won't protect the local resources if there is an exploit, but it may reduce the surface area. This also requires that your users remember which browser to use for what apps.

3. Virtualize Java

Many IT departments install virtual machines for users who need access to Java sites. Running the browser in a local VM can keep Java in a sandbox, which helps restrict access to the sensitive parts of the machine if it is corrupted. But getting users to launch the VM every time they need to access the Java app is slow and painful, and the model breaks down if your users come in from other devices. Cloud-based VDI solutions can provide a basic browser off-machine and off-network, but that is overkill. Users have the complexity of another, slower desktop in a separate window and IT incurs the cost and management overhead.

4. Contain Java

An emerging approach is to run the browser in a cloud-based container. Think of the container as a browser running in a dedicated sandbox in the cloud. The container is an on-demand browser that looks and feels like a native app. The container is built fresh when the session starts, and all Web code is executed remotely, away from the user's machine. The container is destroyed at session end, ensuring no residue is left behind. This allows full access to Java apps without risking your local resources. Some Web-based container services also allow policies to govern access and data use. Containing the app isn’t a panacea, as these solutions do have some gaps when compared to the local browser, specifically around video content.

Regardless of the approach, understanding the browser requirements for your Java app is a good place to start. Java is a practical reality, but if you shift the burden to the cloud, it becomes secure as well.

The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.