Relax! Java is OK – and Easy to Secure

Author: No Comments Share:

It’s become cool, particularly among those that sport Macs, to scoff at Java and pretend that it’s an anachronism that the world doesn’t need. Perhaps it’s a re-enactment by the Apple faithful of Steve Jobs’s disdain for Flash, spurred by Apple’s removal of Java as a default plugin for Safari after Apple itself was compromised by a Java-based attack.  After all, who can resist getting in a dig at Larry Ellison’s expense?

But the fever pitch around Java is bigger than that.  It has grown to the point that the US DHS warned users to disable client-side Java.  Talk about shouting into the wind: Java is here to stay – approximately forever.  And it can easily be made completely secure.

If you need to ask why Java is needed, then you do not work in a real enterprise setting.   Last week I visited a leading manufacturer of heavy machinery, whose  innovative designs are crucial to its success.  It is being heavily targeted as a result.   Like many organizations for which IT is not the focus of the business, the IT operations team is stretched thin.  They do their best to keep up.

The company is being actively attacked using Java as a vector because they are stuck with an old version: They use Oracle R11 as their ERP system, which apparently (I haven’t been able to verify this) requires the client to use Java 1.5.0_17.   Upgrading the ERP system would be disruptive, expensive and complex, and banning client side Java is not an option – everyone, from Finance to Engineering, has to use the system.

No matter how you look at it, the problem isn’t Java.   Nor is it the  “You” in “User”.    Unlike the countless failed attempts to train users not to click on “seemingly unsafe” links or files, I’m going to assert that user training will never succeed since the attacker is always a step ahead of the trainer. (Unpatched) Java, and un-trainable users are with us to stay.

What is the problem? Complex application and OS software environments are vulnerable because they offer a huge attack surface.  Java has been successfully targeted of late because it is a classic example of a complex software environment, and because of its ubiquity and platform independence.   Java meets the economic needs of malware writers: One can target a massive number of deployed systems with one piece of malware.

The response of the security and OS vendors is at best, sad.  The security industry has nothing more useful to offer than advice on how to un-install, or update the Java plugin.  Apple removed Java from Safari last October, and Microsoft FixIt now blocks Java from IE.   For its part, Oracle has repeatedly promised to fix Java once and for all, and a recent blog is telling (the highlights are mine):

In JDK 7.2, Oracle added enhanced security warnings before executing applets with an old Java runtime…  In JDK 7.10, Oracle introduced a security slider configuration option, ….  Further, with the release of JDK 7.21, Oracle introduced the following:

  1.  …  With this update … users can prevent the execution of any applets if they are not signed. 
  2. The default plug-in security settings were changed to further discourage the execution of unsigned or self-signed applets.  This change is likely to impact most Java users, and Oracle urges organizations …to sign [their] Applets
  3. While Java provides the ability to check the validity of signed certificates … the feature is not enabled by default because of a potential negative performance impact.  …In the interim, we have improved our static blacklisting to a dynamic blacklisting mechanism

The Oracle “solution” appears to be

  1. “hope the user does the right thing”,
  2. “make Java unusable”, and
  3. “when all else fails, try blacklisting”.

Depending on the user is a bad idea.  Making Java unusable is a terrible response, both for Oracle and for its customers.  Moreover banning or disabling Java doesn’t address the root of the problem.  Blacklisting is an article of faith for the AV vendors, but I think we all recognize that its time has come and gone.

A Future Proof Architecture

There is a way out of this mess that enables

  • Today’s vulnerable applications & plugins (Flash, Java, Silverlight, Chrome, Firefox, IE, Word, Powerpoint, Excel, PDF, media etc) to run as intended by the vendor
  • New mobile-centric, cloud based applications for consumers or enterprises, to deliver a user experience that fully empowers the user, and
  • With absolute security.

The way out is Bromium vSentry.  We use use hardware isolation on a per-task basis  – to protect the system from every attack.  When the next zero day comes along, the attacker will be unable to steal any information or gain access to the corporate network.    Moreover, the attacker and all persisted state will be simply discarded as soon as the user closes the task window.   No remediation.  No change to the applications or to the end user experience.   And if the endpoint is attacked, Bromium LAVA will provide live attack visualization, with complete forensic analysis – delivered instantly to the SOC.  Check out our new Safely Use Java Apps page to learn more.

Previous Article

Application Sandboxes: A pen-tester’s perspective

Next Article

Introducing Bromium Labs

You may also like