Serious vulnerability in Java 7: another nail in the coffin for Java as a client-side web technology

On Monday, an "extremely critical" vulnerability was announced in version 7 (i.e. all versions 1.7.x) of the Java Runtime.

The vulnerability is effectively that Java's Security Manager settings, controlling permissions that govern critical operations such as file access, network connectivity, running external processes, can be overridden. In particular, the Java web browser plugin normally sets security restrictions ("sandboxing") meaning that arbitrary files cannot be read from the host machine and arbitrary processes cannot be started by a Java program embedded in a web page. The vulnerability discovered in Java 7 effectively allows these restrictions to be bypassed (specifically, this example code does so by making reflective calls via the Javabeans framework).

This vulnerability-- more so than previous cases, it seems-- has sparked a strong message from many commentators that Java applets are no longer a fundamental part of the web infrastructure. The advice given by many industry commentators is that Java is not needed by most users and should be disabled: the security risk it poses outweighs the benefit for non-specialist users.

If for you, Java is still a "core" piece of web technology, then less extreme action you could take:

• using Google Chrome, go to chrome://plugins and ensure that the Java plugin is not set to "Always allow" and only run Java on sites that you trust;
• use another browser, with Java disabled (or a device such as the iPad that doesn't support Java) for browsing sites that are not in your "trusted" list;
• when using a public network (e.g. in a coffee shop etc), use a browser or device that does not have Java installed (e.g. your iPad is safe);
• if you have to use your laptop over a public network with a Java-enabled browser, do so over a VPN.

Of course, whenever you browse to an untrusted web site and/or use a non-encrypted connection over a network with components that are easily controlled by a third party (e.g. in a miscellaneous coffee shop) there is a tangible risk from various possible vulnerabilities. What arguably makes this vulnerability different is that: (a) it is relatively easy to exploit by an attacker; (b) in the race to close the vulnerability, the Bad Guys currently have the "upper hand": an exploit has already been integrated into standard hacking tools whereas no patch is available or announced (at the time of writing).

So... check your Java settings and watch this space!

Update: a patch has been released which partially addresses this vulnerability.