Posts Tagged ‘NoScript’

Decaf Java?

Posted: February 26, 2013 in Uncategorized
Tags: , ,, you’ve heard about the recent security vulnerabilities involving Java. I blogged about it last month in this post.

“Patch and pray” might be a good start for dealing with software issues like this but you can do more. The reason? There’s always going to be another vulnerability and, in some cases, the bad guys will exploit it before the good guys have developed a defense for it — the dreaded “zero-day” vulnerability.

So what can you do? In my previous post I extolled the virtues of the NoScript browser plug-in as one approach. It doesn’t have to stop there, though.

There’s a good article entitled “How to Safely Keep Java in Your Web Browser” that points out just how difficult it is to wean yourself off of Java (the software — not the beverage) along with some possible strategies to lessen the risk. Among the techniques described involves using separate browsers for Java and non-Java content (which is sort of a more drastic version of the NoScript approach).

I hope you find it useful since going cold turkey with Java could be the equivalent of cutting off your nose to spite your face …


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…


Network World has a good summary of the latest zero-day vulnerability in Internet Explorer. The article states that:

Exploiting the flaw allows hackers to execute code — in other words, plant malware on a machine — and opens Windows XP, Vista and Windows 7 to drive-by attacks that only require getting victims to visit a malicious or compromised website.

That means that:

  1. if you use an unpatched version of Internet Explorer (and at the time of this writing that would be all versions since the patch hasn’t been issued) and
  2. if you visit a web site designed to exploit this vulnerability …

you could end up with malware being downloaded to your system without your knowledge.

Clearly, when the patch comes out, you should apply it. Better still, turn on Windows Update and let it do the dirty work automatically.

In the meantime you can either choose to use another web browser such as Firefox or Chrome or just be really careful which web sites you visit.

In fact, you should do that last bit every day anyway. The problem, of course, with that is that you can’t really know for sure which sites might infect you but you can, however, lower the odds considerably by not visiting unknown or dodgy sites.

Just as in the physical world, sticking to the well traveled streets rather than veering off into the alleyways in bad neighborhoods and you will be safer but, crime can happen anywhere.

That advice holds for any web browser, for that matter too. So, while this particular attack won’t affect you if you use Firefox, there’s no guarantee that the next similar attack won’t. Still, at the end of the day, one argument for using Firefox rather than IE is NoScript plug-in that allows you to turn off Java and JavaScript by default for web sites you don’t know whether you should trust or not. That’s one of the best defenses against drive by attacks.

It can be a pain at times as some sites won’t render correctly without these features turned on but at least it puts you more in control of the situation and that can me the difference between dodging or taking a direct hit on the next drive-by browser attack.



So just as I start up my new security blog on WordPress with a video where I talk about some of the risks (including malware) of social media, guess what shows up?

You got it! A story about 30,000 WordPress blogs being infected to distribute none other than malware. Here’s a link to the story:

This is really nothing new, of course. Drive-by download attacks have been around in various forms for years. I wrote about the risk in my book a dozen years ago when most users assumed that the mere act of browsing a web site was safe.

Unfortunately, as long as we have browsers with bugs, some of those bugs will result in security vulnerabilities and some of those vulnerabilities will be exploited.

No defense is 100% foolproof but one of the better ones in this area is the NoScript add-on for the Firefox browser. NoScript prevents mobile code such as JavaScript, Java and Flash (inherently avoids the exposure of ActiveX that exists in Internet Explorer) from being downloaded and executed by your browser for untrusted sites.

It does result in some pages not being rendered correctly but you can either temporarily override the block or add the site to your trusted list to get around this issue. It’s more trouble, but well worth the effort in my opinion.