Posts Tagged ‘Java’

The sandbox is leaking …

Posted: April 8, 2013 in Uncategorized
Tags: , ,

Sandboxing is a great security technique. In theory it isolates programs running in it from the rest of the system it is running on, therefore, preventing the spread of malware, escalation of privileges, data compromise and all sorts of other problematic interference. In the browser context, a Java applet is intended to be downloaded automatically when a user visits the server it is stored on and run inside the protected walls of a secure sandbox. It’s a good model… when it works.

Sometimes it doesn’t, as demonstrated in the latest in a growing line of Java exploits as described in an article by the Institution of Engineering and Technology where theory and practice fail to converge:

By using a vulnerability in a Java reflection API, which has been the target of recent attacks, Forshaw was able to disable the Java sandbox and perform actions under the privileges of the logged in user, including reading and writing files and executing new programs.

In general, Java’s security model is much more robust than some of its alternatives but it never hurts to remind ourselves that it isn’t perfect. No software of any real complexity is. This is why you have assume that any security defense can and will be breached and architect a solution that is resilient in the face of such a failure.

Another aspect of Java that is working against the good guys stems from one of its greatest strengths, and that is that it is cross-platform in nature. In other words, a developer can write it once and have it run on Windows, Linux, Mac OS and so on. Generally speaking, that’s a good thing. However, it also means that bad guys can write exploits that are able to cut across a wide range of platforms as well. Previously, such a feat would have been far more difficult due to the uniqueness of each OS.

Yet another area of concern is that while we continue to learn of more and more vulnerabilities in Java, we are also becoming keenly (and painfully) aware of just how many people are running old versions of it on their systems, leaving them open to an increasing number of threats.

A recent report from Websense asserts that only 1 out of 20 systems is running the latest version of Java and that 94% of systems were vulnerable to a recently discovered flaw. 

Ouch! And in this case, the sandbox is leaking a lot more than just sand …


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…


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.