New Java Security Settings: More Proof That Oracle Hates You

by Bob Plankers on February 6, 2014 · 17 comments

in Outright Rant,Security,System Administration

I began the day yesterday updating to Java 7u51, after which absolutely none of my enterprise Java applications worked anymore. I could not reach the consoles of my Rackspace cloud servers. I could not open the iDRAC console on my Dell PowerEdge. They all exited with some error about the Permissions attribute not being set. Being the guy that I am I decided to search for the error. Turns out that 7u51 sneaks a major change in a point release: on the default Java security slider setting of “high” no applet may run if it’s self-signed, unsigned, or is missing the Permissions attribute.

Unfortunately, that describes all enterprise software, at least all the current versions of things I’m using.

This isn’t a trivial change. This is the sort of change that accompanies a major version, heralded far and wide for months, with customers given a choice about deployment and testing. Is that what happened? No, because this release is also a security update. So people across the globe autoupdate and suddenly can’t do anything, because absolutely no Java applets meet these criteria (probably not even Oracle’s own).

So into the Java control panel we go:

Java Control Panel, 7u51

What sort of company labels the bottom part of a three-position slider “medium” when the description is “least secure?” Oh, a disengenuous one, that’s right.

The fix is basically to disable security, either globally by moving the slider (as I did, because I’m not a moron and can tell what the security prompt is for)[0] or for specific sites (like my entry for Of course, none of this is really what I want. I don’t want to trust implicitly, because I don’t want just any applet running from there. I only want the console applet that I requested. I don’t want to lower all my security settings, either, but I’m going to, because I need to do my job.

Assuming that Oracle is trying to fix some legitimate problem, they’ve now completely bungled their shot at it. By changing defaults in what is essentially a point release they’re ensuring that no software has been updated to conform to their new standards, and users will have to change the security settings to simply continue doing their job. The right time and place for a change like this is a major version release, when all other parts of the support ecosystem already need to test and recertify against the new version.

Instead, it’s a mess, which is just par for the course when working with Oracle.


[0] Pre-emptive snarky comment: “Well, that’s the problem they’re trying to fix, people are morons.” My coworkers and I have a saying, “you cannot fix people problems with technology.” This is squarely a people problem, and the “fix” here doesn’t make it less of a people problem because they botched it. Besides, if I’m an attacker I’ll just recompile my malicious applet with a Permissions manifest and go back to slurping up your credit card numbers. It wouldn’t surprise me to learn that malicious apps are already updated.


Comments on this entry are closed.

Previous post:

Next post: