Michael Horowitz

The ugly side of the latest Java updates

October 18, 2012 6:50 PM EDT
Lets start with the standard background facts about the October 16th updates to Java:
 
  • 30 bugs were just fixed in Java and everyone using Java should install the new versions (Java 6 Update 37 and Java 7 Update 9 are both considered current).
  • Updates are available for Windows, Linux and the last three editions of OS X.
  • If you don't need Java remove it. The home page of my JavaTester.org site has more on this. (Note: JavaTester.org is a site that I created and maintain. It is not associated with Oracle in any way).
  • Java is used by both installed applications and websites. If you only need Java for an application, disable it in all your browsers. OS X users on Lion and Mountain Lion had Apple do this for them (more below). Windows users in this situation may want to consider the portable version of Java available at portableapps.com. 
  • If you need Java for a website, enable Java in a browser used only on the site that needs it. For all other websites, use a browser that has Java disabled.
 
Now, the ugly stuff. 
 
The biggest issue is that Oracle didn't patch all the known problems with Java. As a result, even these latest and greatest editions of Java remain vulnerable to a known critical flaw. 
 
Adam Gowdiak is the security researcher who found many of the recent flaws in Java. His last flaw became public knowledge on September 25th. Since the problem was exploitable on Java versions 5, 6 and 7, Gowdiak estimated that it put 1 billion users at risk
 
A couple security organizations, Heise and Kaspersky, have been in contact with Gowdiak about how well the latest versions of Java patch the flaws he discovered. 
 
Gowdiak told Heise Security "that a critical security hole that allows attackers to break out of the Java sandbox continues to exist in Java". He claims that Oracle told him that the just-released package of 30 bug fixes was "already in its final testing phase" when he reported the September 25th flaw. In other words, he was too late to the party. He told Kaspersky the same thing.
 
The flaw that puts a billion users at risk won't be patched until February 19, 2013. 
 
This is not to suggest, in any way, ignoring the latest updates to Java. Just recognize that they make you safer (30 bugs were fixed) rather than safe. 
 
 
CHECKING FOR UPDATES ON WINDOWS
 
Whenever the next batch of fixes is released, Java users need to be notified about them as soon as possible. On a Mac with Java 6, just configure Software Update for daily checking.* On Windows, Java defaults to checking for updates only once a month. Bad default. 
 
When I started writing this, the update schedule was an afterthought. The schedule is available in the Java Control Panel in the Windows Control Panel. Just open it and go to the Update tab. The user interface is simple and clear.
 
But then I tried it on two PCs. I installed Java 6 on Windows 7 and Java 7 on Windows XP. In each case, modifying the Java update schedule was problematical. If you're getting sick of this, so am I. 
 
On the Windows 7 system, because I was logged on as a restricted/standard user, the options to change the schedule were disabled. In almost every case where administrative privileges are needed, Windows prompts for an admin password. Not here. I had to logon as an administrator to tell Java to check for updates daily rather than monthly. 
 
This brought up the worst kind of bug: silent. Modifying the update checking schedule seems to work. There are no errors or warnings. But it doesn't work. I just happened to open up the Java Control Panel a second time, after telling it to check for updates daily. Lo and behold, the schedule was still monthly 
 
My first guess was that it had something to do with running a 32 bit version of Java on a 64 bit system. But no, Oracle themselves, suggest using the 32 bit edition of Java on a 64 bit version of Windows. 
 
Some online searching revealed this to be a known problem. According to Oracle, it is an issue on both Windows 7 and Vista. The solution is ugly, you have to run a very long command from an elevated Command Prompt. I did, and it worked. The only good news, is that this works even when logged on to Windows as a restricted user. 
 
Speaking of my first guess, the Update tab is not included in the 64 bit versions of Java, another reason to stick with the 32 bit version. 
 
On the Windows XP system with Java 7, things were even worse. 
 
There was no Java Control Panel in the Windows Control Panel. Even though I was logged on as an administrator, it was gone. A little hacking however, got it to run. 
 
On Windows 7, I used Process Explorer to determine that the Java Control Panel is javacpl.exe. Then, on Windows XP, I found this program in 
 
C:\Program Files\Java\jre7\bin
 
Sure enough, running it produced the Java Control Panel and the Update tab. It's a simple matter, at this point, to make a shortcut to javacpl.exe so that it can be run again without having to search for it. 
 
Unfortunately, Windows XP has the same problem with updating the schedule: it seems to work, but doesn't actually take hold. As with Windows 7, there are no visible errors. Nothing is logged in any of the event logs either. Java just ignores you. 
 
I don't have an answer here. If anyone knows how to make Java 7 check for updates daily on Windows XP, please leave a comment below or email me at my full name at Gmail. 
 
 
LEOPARD MACS 
 
Anyone running Java on Leopard (10.5) should stop doing so. Apple is not providing Java updates for Leopard. 
 
People using Snow Leopard (10.6) are probably the best off in the Mac community. They simply get Java 6 Update 37 from Apple using the standard software update mechanism and get on with their lives. My Mac is running Snow Leopard. 
 
 
LION MACS 
 
Macs running Lion (10.7) and Mountain Lion (10.8) are in a more complicated situation. 
 
These systems shipped without Java and users could have either installed Java 6 from Apple or Java 7 from Oracle. 
 
A system that started out with Java 7 from Oracle should be fine. Install the latest Java update and you're done. It is, however, unlikely that many Lion and Mountain Lion systems started out their Java life at version 7. Up till now, Java 6 has been provided, by default, by Apple.  
 
Systems that started out with Java 6 are the big losers in the Mac world. 
 
Apple's latest update to Java 6 takes the drastic step of disabling Java in all browsers. Java 6 is thus only available to installed applications. Hopefully, that's sufficient for you. 
 
If, however, you need to run a Java applet on a website, then Apple forces you to install Java 7 from Oracle for just that purpose. This results in both Java 6 and 7 being installed and, no doubt, permanent confusion as to what software is using which version of Java. Not to mention being on the hook, going forward, for updating both versions. For more on this, see Apple gets aggressive - latest OS X Java security update rips out browser support.
 
Another issue for Macs forced to install Java 7, is that it's not supported by Google's Chrome browser.  Java 7 also entails changes to the Java Preferences utility, used to configure Java.
 
I can remember back when Java was the next big thing. Now, it's all but a curse word. 
 

* I don't have access to a Mac running Oracle's Java 7, so I can't verify how it self-updates. According to Oracle, Java 7 on OS X checks for updates once a week, assuming you invoke Java. To manually check for new versions of Java, run the Java Control Panel by clicking the Java icon in System Preferences. Then go to the Update tab. 

Update: A new installation of Java 7 (32 bit) on Windows 7 64 bit had the same problem configuring the frequency of update checking. It defaulted to checking for updates once a week and notifying about updates "within a month of its release." Modifying the update schedule to daily, even when running as an Administrator did not take, requiring the same fix as described above with Java 6.  Oracle's advisory Why are the Java update settings not saved in the Java control panel? says that the problem only applies to Java 6. It seems to apply equally with Java 7.  November 4, 2012.