Managing Legacy Java Versions

Java is currently the leading exploit vector for Windows machines, and Java vulnerabilities are packaged into many of the “exploit kits” available in the darker corners of the Internet (see http://krebsonsecurity.com/2010/10/java-a-gift-to-exploit-pack-makers/). Internet Explorer, Flash Player, and even the Windows operating system itself have done a good job of either improving the security of their products or improving their patching processes. Java, however, still lags noticeably behind in both user/media awareness and quality of code. According to some statistics, Java vulnerabilities account for up to 70% of successful exploits, making it a veritable nightmare from a security perspective.

When Citrix announced that its NetScaler console was finally Java-free, I rejoiced in the knowledge that my home machines no longer needed to run Java at all. But in the enterprise, the chances of being able to do this are unfortunately slim. Hundreds of applications run Java (even your car, if you believe that awful splash screen), and that’s not even beginning to count applications developed as in-house tools. What makes it worse is that often applications require specific, older versions of Java to function or to be supported. In these situations, user desktops or terminal servers end up with the “lowest common denominator” issue: they have the lowest version of Java installed and running that all of the Java apps will support. This means that they end up running a version that is potentially chock full of security holes—leaving a huge target for attackers to aim at.

In the virtualization world, there are technologies you can leverage to avoid problems such as these. Packaging applications, using isolation techniques such as App-V or ThinApp, can allow you to restrict the execution of these “vulnerable” versions of Java by running them in isolation, while maintaining the latest “secure” version in the main image. However, packaging applications in this way has an overhead of time and resource—and not all applications can be packaged successfully. There is also the issue of browser-based applications: packaging these applications (in particular, those that use Internet Explorer) can be especially challenging. Complexity is often one of the (many!) Achilles’ heels associated with virtualization—particularly desktop virtualization. Can’t we find a simpler way to achieve this?

Well, we can. In my experience, two tools that deal specifically with the Java “lowest common denominator” issue are Browsium and FSLogix. Both products have other features besides the ability to deal with this problem, but they deal with it in similar ways, by loading specific Java versions depending on contextual awareness.

FSLogix Java Rule Editor

FSLogix is a nifty product that sits somewhere in the “app layering” category—but doesn’t really, as it puts all your applications in the base image and then hides access to unneeded apps based on various configurable conditions. It’s sort of like “reverse” or “negative” app layering, if I had to coin a phrase for it. Fellow TVP Analyst Jo Harder examined FSLogix’s core product in her post The Logic of FSLogix.

The Java Rule Editor is a separate program that comes with the core FSLogix product. It’s pretty simple to get up and running: install the FSLogix agent on an endpoint, install the console on an admin endpoint, and you’re good to go. You can then configure specific installed versions of Java to run based around a certain URL or a certain application process.

Browsium Ion

The Browsium core product, Catalyst, is more specifically targeted in its general features. Browsium allows you to specify a certain browser for use with specific sites. If, for instance, you want google.com to always open in Chrome, this is the sort of thing you could enforce with Browsium, without any interruption to the user. If your corporate browser is IE11 but you have a banking site that only works in IE8, this again could be configured via Browsium, leveraging the compatibility mode engines but providing them in a much easier-to-use interface.

Browsium Ion is the product that does Java version management, as it specifically deals with web application remediation, rather than multiple browser management. It is remarkably similar in deployment: add-on to the endpoint, console on the admin endpoint, and you’re done. Putting the Java rules together is slightly more complicated, but still very straightforward. The only real difference complexity-wise is that Browsium’s Ion tool does more than just Java version management, whereas FSLogix’s Java Rule Editor does only that.

Comparison

The two products work in very similar ways, both in terms of deployment and management. Under the hood, they may well behave differently, but the end result remains the same: you can specify particular Java versions for specific sites. FSLogix can specify Java versions for URLs or certain non-browser applications, whereas Browsium works only on web-based applications. It’s worth noting, though, that non-browser-based Java apps are significantly rarer than the browser-based ones.

The killer question in this debate is: “What keeps malicious web pages from invoking old versions of Java if they’re installed on my endpoints?” FSLogix’s product is based around a file system filter driver that can selectively hide files and Registry keys based on configurable conditions, and it is this same filter driver that is used to prevent malicious actors from accessing the legacy versions. Browsium uses an “opt-in” model similar to that leveraged by Internet Explorer: only the latest version of Java can be accessed by a web page unless Ion specifically “surfaces” the legacy version when instructed to by a rule. How this operates when a malicious process, rather than a malicious web page, is the attack vector may be a point worth exploring, but it is clear that both products use sandboxing techniques to try to address this particular question.

Of course, if you also have an issue with compatibility around different browers or browser versions, then Browsium is the clear winner. For instance, you could deploy the latest version of IE11 in your enterprise but still maintain compatibility with websites that only run in IE7. Microsoft does now have EMIE (Enterprise Mode for Internet Explorer), which is designed to address some of these issues, but for web applications or sites with any degree of complexity, Browsium is still a much better option.

However, if browser compatibility isn’t such a pressing issue—or if you can mitigate it with other tools—then FSLogix offers a lot more by way of other features. The core product is very interesting to those looking to simplify management of gold images and licensing requirements. Although there may be a few questions about how well it can scale (particularly in environments with vast numbers of applications), it is certainly a simple, elegant idea that seems to do exactly what it says on the tin. There is also the point about how well your investment would stand up if vendors finally got their act together and made their products work with the latest versions of Java or browsers. With Browsium, you would probably be left with a product that wasn’t actually doing anything any more, whereas with FSLogix you’d still have the other features. Still, though, the idea that all vendors might do things the right way is probably more of a nirvana than a realistic possibility!

Finally, there’s the price point. Naturally, there isn’t a specific price available, but I’ve heard tell from some customers that Browsium in particular was overpriced for them, in light of what features it gave them. Now, if you need to remediate browser compatibility for many thousands of users, you will probably get a lot of value for your money, but if you’re only dealing with a small subset of users, it may not be such a compelling deal. It really depends on how much of an issue you are facing.

Summary

Both of these products provide a clean, simple, and manageable way to run legacy Java versions based around specific configurable conditions. They also both provide other—markedly different—functionalities that you may find tremendously useful, depending on your environment and the behaviour of the applications in it. With regard to the Java issue, I can concur that both products do an excellent job of providing the right version without interruption to the end user. It simply remains for you to evaluate all of the other factors to decide which would be the best fit for your needs.