What to do about Java in Windows (and elsewhere)?

Header for the CERT/SEI vulnerability note on Java.

OK, by now everybody’s heard about the Department of Homeland Security’s Advisory (originally released on 1/10/2013, most recently updated yesterday, 1/17/2013). Here’s the meatiest part of that document’s recommendations:

Unless it is absolutely necessary to run Java in web browsers, disable it as described below, even after updating to 7u11. This will help mitigate other Java vulnerabilities that may be discovered in the future. [The advisory includes pointers to descriptions for how to disable Java in most major modern browsers, and there are plenty of other articles on the Web that explain how to do this for less popular ones, too.]

The guiding principle behind the DHS recommendation is risk avoidance — namely, that the only way to avoid future zero-day vulnerabilities in Java is to turn it off, since there appears to be no way to guarantee these can’t happen again. In fact, the very day after Oracle posted update version 11 (1/15/2013), a cybercrime forum posted a message that a new zero-day exploit kit for Java would be sold off to the two highest bidders at a starting price of $5K (source: InformationWeek Security). In fact, InformationWeek security maven Mathew J. Schwartz quite accurately labels Java an “attack magnet” in a recent story entitled “10 Facts: Secure Java For Business Use.” Among his recommendations that fall shy of what the DHS Advisory implores (“disable Java”), he mentions use of management tools like PolicyPak to restrict access to questionable or unauthorized Java code (and can even disable Java completely by policy, should that prove necessary). He also mentions use of white-listing tools such as NoScript for Firefox or Adblock Plus (for Chrome, Firefox, and Opera), both of which permit whitelisting of specific sites for active content while denying runtime access to all other active content.

No sooner released than it becomes subject to a zero-day attack of its own!

My favorite among his recommendations is to maintain one browser to use for everyday surfing and Web access with Java disabled, and another, different browser to use only when accessing known good Java-based active content that must be used for legitimate business reasons. One would turn only to the Java-enable browser when circumstances compelled its use, and avoid using it otherwise. Schwartz also suggests that Oracle should patch faster, perhaps by devoting more resources to its upkeep and maintenance. The company’s planned two-year release cycle for Java, scheduled to begin with version 8 later in September, 2013, may or may not help to improve security. What would help, however, is to decouple the primary Java runtime environment from the Java browser extension, which means that end users often install and expose that extension to attack without even being aware of the exposure that creates, and the vulnerabilities to attack it presents. Schwartz quotes an expert from Stach & Liu as saying “Since so few websites legitimately use the Java browser extension, it is most prudent to disable it entirely” or perhaps to “only re-enable it for specific sites determined to be trustworthy.”

These days the rule of thumb for Java use seems to be “Use only when nothing else will work, and only when what’s used it known to be safe from potential vulnerability and attack.” Because it’s so hard to be sure, the DHS recommendation to disable first, and ask questions later, makes a depressing amount of sense. I still have to visit enough Java-based websites to write about them, that I’ve set up a special VM (snapshotted daily) where I keep a browser with Java enabled, and only work on that VM when I absolutely must use Java. If the worst happens, I can always toss an infected or exploited VM, and revert to the previous snapshot. It’s not completely foolproof or totally secure, but it does work, and it will protect my primary production runtime environment from attack and potential compromise.