Windows Enterprise Desktop

Jan 18 2013   4:53PM GMT

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

Ed Tittel Ed Tittel Profile: Ed Tittel

Header for the CERT/SEI vulnerability note on Java.

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!

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.

5  Comments on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    Would you use any other software tools or products that are subject to critical zero-day attacks? It's not clear why this particular issue is raising such awareness when so many previous vulnerabilities outside of Java have mostly passed notice. -- Tom
    125,585 pointsBadges:
    report
  • Ed Tittel
    You make a good point, Tom, but the recommendations come from CERT/DHS and are primarily aimed at US government employees (or rather, the IT admins who cater to their computing and Internet access needs). While it's true that I laid out a potential strategy for avoiding trouble based on those recommendations, they originate from elsewhere.That said you raise the very interesting question of why we use software subject to zero-day attacks in general. The real answer is "because it's what we've got" which could then even translate into "because we have no choice." In such a situation, adding extra layers of protection -- as I attempted to do with an insulated VM inside its own separate runtime environment -- makes even more sense, if you ask me.But thanks for asking an important question: Windows itself is surely subject to the same sort of flaws that Java is, and we continue to use it by the billions of copies daily as well.Best wishes,--Ed--
    4,560 pointsBadges:
    report
  • TomLiotta
    I understand most of it. It's just that particular item seems to have caused more of a stir than others in the past have. Is it because DHS is referenced in association? Is it because Java has had a fairly good history (not perfect) and this is therefore out of the ordinary? I didn't notice any attention to CVE-2012-4792. Is it just because it's "Oh, well, same old thing"? -- Tom
    125,585 pointsBadges:
    report
  • TomLiotta
    And to clarify, I'm not asking about you. I'm curious about the general treatment. It's even been on TV newscasts. -- Tom
    125,585 pointsBadges:
    report
  • Ed Tittel
    Dear Tom:Again some good questions and concerns. The reason DHS weighed in so heavily speaks to the pervasiveness of use of Java in government installations, some whose attack and compromise could have serious results. The nature of the vulnerability -- remote code execution -- is such that it could result in complete system takeover if and when the right exploit should be foisted, followed by execution of just the right elements of malware. No, it's not that this is a bad exception following generally "good behavior" where Java is concerned (it's been the focus of an increasing number of exploits over the past 18 months or so, but even before then its history was not unblemished). There's a BIG RISK here which is why it's receiving a lot of attention, though some of it may be more for sensationalism's sake.HTH,--Ed--
    4,560 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: