If you’re a security geek, chances are you’ve already heard plenty about the latest “hair on fire” scenario involving Java 7. If not, here’s a very brief discussion of what all the fuss is about…
First of all, Java is a programming language than was designed to allow for execution on a wide variety of platforms without recompiling. Its “write once, run anywhere” value proposition has been compelling in an age where we want to connect all sorts of operating systems and hardware platforms into a unified experience over a worldwide Internet. As a result it has proliferated to the point where it runs on everything from large servers to medium-sized desktops/laptops to small handheld phones.
However, like all software, Java has bugs and, not surprisingly, some of them are security-related. The current fuss involves a type of vulnerability called a “zero day” because it involves a previously unknown weakness for which there was no readily available patch. This means that an attacker could potentially exploit this hole and systems would be defenseless until a fix was developed (in this case, by Oracle, who owns Java) and the fix applied to all vulnerable systems. Sounds scary, right?
Well, it is, but there are some things you can do to lessen the odds you will be victimized, and since some security experts are claiming it could take two years to develop a “real fix” to the problem (as opposed to some more stop gap measures), we had probably think about this problem strategically and settle in for the long haul.
In addition to applying the newly available patch many are advising that Java be disabled in web browsers to lessen the risk. The well-respected US Computer Emergency Response Team (US-CERT) put it this way in their recent alert:
“This and previous Java vulnerabilities have been widely targeted by attackers, and new Java vulnerabilities are likely to be discovered. To defend against this and future Java vulnerabilities, consider disabling Java in web browsers until adequate updates are available. As with any software, unnecessary features should be disabled or removed as appropriate for your environment.”
So, what can you do after applying the latest patch(es)?
- Disable Java in the browser: You can see instructions on how to do this in the US-CERT alert or in this ZDNet article.
- Remove Java entirely: Some advocate the more drastic option of removing Java entirely from your system. I’m not a fan of this approach, though, because, at least in my experience, there are too many things I need to do that require Java so this really isn’t practical.
- Selectively enable Java in the browser: My personal preference is to use a a Firefox as your browser along with the NoScript extension. This option allows you to turn off client-side functions such as Java, JavaScript, Flash and others by default and then select which trusted sites you’d like to enable these capabilities on. It won’t guarantee safety but it also won’t cripple your system in the interest of security.
Oh, and if you’re responsible for securing your organization against these types of vulnerabilities, it would be worthwhile considering a more holistic, end-to-end approach that would allow you to push patches out automatically to all systems as well as tweak settings to disable Java (or similar capabilities) temporarily in a way that requires no intervention by end users. IBM Endpoint Manager is one such tool that allows for this sort of centralized management.
Of course, the usual advise regarding avoidance of sketchy web sites and not clicking indiscriminately on links in emails and SMS text messages applies as even the best security tools will eventually be vulnerable to the next zero-day exploit. So rather than looking for a quick fix, think of this as the “new normal” going forward because there will be plenty more similar situations to come…
Inside Internet Security 