No Heartbleed holes in Java, but here comes a sea of patches anyway

library
crime | hacking | security

Oracle’s quarterly Patch Tuesday updates for April 2014 are out.

As usual, there is a massive menu of patches to navigate, given the large number of Oracle products available.

The fixes we’re particularly interested in here are for Oracle Java SE, the Java Standard Edition that many of you will have installed:

Java in practice

Remember that there are two sorts of Java program.

There are full-blown applications, which you download and install locally, just as you might install any other software such as Microsoft Word, Apple Keynote or the Apache web server.

And there are Java applets, which are delivered directly into your browser as you use the internet, and run in a deliberately restricted version of the Java environment inside your browser.

The browser is where most of the risk from Java presents itself, because that “deliberately restricted environment” doesn’t always impose the limitations it should, due to software vulnerabilities in Java.

→ Example: an applet arriving from a remote website shouldn’t be able to read files stored locally on your hard disk. But if cybercrooks find a way to trick the Java runtime into letting applets access files that ought to be invisible, you have a false sense of security, not to mention an exploitable information disclosure or data leakage vulnerability.

Regular readers will know that our recommendation (and Oracle’s own current default setting) is to turn off Java in your browser unless you know you need it.

Having said that, you should be keeping up with Java patches even if all you use are Java applications, just to ensure that you aren’t opening up unexpected holes when you run them.

And this quarter’s Java SE patches certainly close lots of holes:

37 vulnerablities are patched.
35 of them are what Oracle calls “Remote Exploit without Authentication,” making them especially dangerous if you have Java enabled in your browser.
All 37 patches affect the “bleeding edge” Java SE version 8.
All but three of the patches affect Java SE version 7u51.
Java SE 5 and 6 get updates, but they are only available if you are on a support contract.

For your reference, Java SE 8 users go to version 8u5; Java SE 7 goes to 7u55; Java SE 6 goes to 6u75; and Java SE 5 to version 5u55.

Java SE and Heartbleed

Of course, these latest patches were scheduled months in advance, and with 37 vulnerabilities plugged, you can be sure that the coding and testing of the updated sofware didn’t happen overnight.

So that begs the question, “What about Heartbleed?”

Oracle, as it happens, has done an impressively systematic job of categorising its products’ exposure to this bug, which can allow programs that use OpenSSL for encrypted connections to be tricked into leaking data, possibly even on an industrial scale.

And the good news, at least for Oracle Java users, is that Java SE doesn’t include or use OpenSSL, so the Heartbleed bug wasn’t fixed because it wasn’t there to patch in the first place.

Phew!

Nevertheless, as Oracle accurately but rather verbosely reminds us:

Note that the surrounding technical environment deployed around [Java SE] should be checked for the presence of other components, which may be affected by this vulnerability.

Ironically, “surrounding technical environments” that are affected (though with patches available) include Oracle Linux 6 and Solaris 11.2, so don’t forget your updates if you use either of those.

Some tips to remember about Java

Java is not JavaScript. Turning off Java in your browser will not stop sites that rely on JavaScript from working properly.
You probably don’t need browser Java. If you still have it turned on, try turning it off and see what happens.
You can allowlist applets (browser Java programs) for individual websites in the Java control panel.

For some fascinating insights into Java, its relationship to JavaScript, its history and how to manage the risks it brings, why not listen to our Techknow podcast All about Java?

STE WILLIAMS