OFFICIAL SECURITY BLOG

We’ve moved! You can now read the latest and greatest on Mac adware and malware at Malwarebytes.

Java problems continue

Published February 1st, 2013 at 7:02 AM EDT , modified February 1st, 2013 at 7:02 AM EDT

Java’s problems continued to worsen this week, with no signs yet from Oracle of a fix. First was the quietly-announced discovery of a fourth Java 7u11 vulnerability on Monday by Adam Gowdiak. Then, late Wednesday night, Apple pushed out a change to the XProtect.meta.plist file, blocking all Java web plug-ins below version “1.7.11.22,” causing Java-using Mac users to complain loudly online.

Java’s repeated security issues over the past couple years, and the difficulty that Oracle has had in dealing with them, have become a major problem. Java vulnerabilities were directly to blame for last year’s most widespread Mac malware to-date: the infection of 600,000 machines with the Flashback malware. Unfortunately, many site managers are not getting the hint, and continue to force users to rely on Java.

In many cases – coupon-printing sites, weather sites, online game sites, etc – uses of Java are frivolous, and users should simply avoid these sites entirely. These things are not worth risking an infection and the potential problems such things can cause. Other uses are more important. Some bank sites, for example, require customers to use Java to access their online accounts. However, my take on this matter is, why would you use a bank that uses a technology that is known to be insecure to provide access your money? I wouldn’t trust my money to a bank that locked up the vault at night with an old-fashioned skeleton key, and neither would I trust one that requires Java to access its “secure” web site.

Worst are the government or enterprise custom web apps built with Java. These, unfortunately, have little chance of being eliminated in a timely fashion, and people’s jobs depend on using those apps. In such a case, there’s little you can do other than voice your objections to anyone in charge. To protect yourself in such situations, I strongly recommend using one web browser to access those specific sites only, and a different one entirely with Java disabled for all other web surfing.

Adding to the confusion, Apple has, twice now, chosen to block insecure versions of the Java web plug-in, just as it has in the past for insecure Flash plug-ins. Unfortunately, both times it was done this before there is a patched version of Java available. I personally have no problem with this whatsoever. People who use Java need some good slaps in the face to get their attention, and make them realize what the dangers are. The problem is that Apple has not chosen to provide any information to the people who suddenly find they can’t use Java anymore, and has not provided users whose jobs rely on Java any way to opt-out. Mozilla has similarly blocked Java in its Firefox web browser, but the difference is that Firefox allows Java applets embedded in web sites to run after the user clicks on them and clicks through the warning Firefox presents. This provides a user more options than Apple, but at the same time, many users are accustomed to clicking whatever they have to click to get something to work, without ever reading the text of what they’re agreeing to. I don’t know what the ideal solution is, but neither of these companies have found it yet. Still, blocking insecure versions of Java is an important thing to do, and I applaud their efforts.

3 Comments

  • Chris says:

    The airline I work for uses this software to communicate with its employees. Since Wednesday night I cannot access any of my scheduling or pay information. I wish I had been asked before someone without direct knowledge of my situation decided to disable it for me. Is there any work around that I can use with a site that I know and trust?

    • Thomas says:

      You could try using Firefox for those sites. My understanding is that it should work. Though it will also block the plug-in, it does so in such a way that requires you to click each applet and confirm that you want to run it to make it load. I do not have any first-hand experience with that, however.

  • Graham Perrin says:

    Apple Xprotect blocked an Oracle distribution of Java more than twice. A 2012 blockage went unnoticed by most users.

    The first incident in January 2013 might have been excusable if Oracle was taken by surprise. But I doubt that Oracle was ignorant to the power and implementation of Xprotect. Consider the 2012 blockage, and so on.

    For the second incident in January, the confusion is inexcusable. Oracle should have been prepared for their standard page, to which Apple refers, to respond appropriately to browsers that are recognisably Mac-based.

This post is more than 90 days old and has been locked. No further comments are allowed.