Why an outdated Java Plugin is so serious

decoder

14

Recently, Mozilla responded to an imminent threat to Firefox users who have an outdated Java plugin installed: Vulnerable versions of the plugin were blocked automatically (see blog post). Since then, I’ve been asked a few times why this is important; others have complained that their <any large number> corporate/government installations don’t work anymore because they depend on an outdated Java version (note that some of these problems/complaints were probably caused by a bug in the initial deployment of the blocklisting entry itself that is now fixed). While we all understand that an operational Java Plugin is absolutely crucial for some users, I’d like to emphasize how critical the situation requiring the block is by providing more details concerning this incident and why it is indeed more serious than some people might think.

What’s wrong with the blocked version of Java?

With the most recent Java update, Oracle fixed quite a few security vulnerabilities (see advisory page), including a vulnerability listed as CVE-2012-0507. Up to this point, this isn’t really unusual, as most of these updates fix one or more security problems.

However, not even 6 weeks after the release of the Java update, the Microsoft Malware Protection Center received malware samples that exploit the specified vulnerability in a very reliable way and use it to install a well known trojan, called the ZeuS bot. There was now evidence that the vulnerability was not just theoretical, and had become a practical avenue to infect machines with malware. You can read the full blog post from Microsoft here (this is a technical post, so it’s likely only interesting to you if you have a technical background).

“I’m not getting attacked anyway”

Shortly after the Microsoft post, Brian Krebs published a blog post on the topic, stating that the exploit is now being integrated into well known exploit kits, e.g. the Blackhole exploit kit. These kits can be purchased on the black market and are usually integrated invisibly into hacked websites or indirectly served on websites through hacked content providers (imagine the number of vulnerable users you can reach when you break into an advertisement server and include your malware into banners served to other sites). With this step, the threat became more serious: Unless you just don’t browse the Internet at all, the risk of getting infected is very real. Of course there might be a minority of users that only ever browses a corporate intranet which will mitigate the risk, but this isn’t really the common use case for a web browser. If a user absolutely needs the older, vulnerable version of Java, they can still bypass the warning.

“I have a Mac, I’m safe”

While this might have been true at some point in the past, the threat landscape for Mac/OS X has changed quite a bit in the last few years. As the popularity of the Mac platform has grown so has its attactiveness as a target for attackers. Only a few days ago, F-Secure announced that the Flashback trojan, a well known piece of Mac malware, is now exploiting the very same vulnerability we’ve been discussing so far. You can read the post here to get all the technical details about it. According to recent reports, the number of infected Mac/OS X machines recently grew rapidly over half a million and is still growing. As such the threat to Mac users is evident and imminent, thus prompting our response on all platforms. Note that Apple has recently released a Java update as well that addresses this vulnerability.

Summary

In reviewing the actions and threats for this Java vulnerability, or, for that matter, any security issue, we take the balance of security vs. usability very seriously. This situation is an instance where we felt the balance had tipped towards taking a security action that has a minor adverse affect to the user community as a whole. The desired goal is to protect our users, to encourage them to upgrade to more recent, secure versions of plug-ins and to maintain our history of thoughtful security action.

Acknowledgements

Thanks to the various people involved in getting the proper blocks in place so quickly, that was an amazing job. Thanks also to Curtis Koenig, Dan Veditz and Ian Melven for reviewing/editing this post :)

14 responses

  1. kang wrote on :

    A friend browsed the web with a vulnerable version of java during a week while his stay at my place on a spare windows desktop comp I have, and got his local account infected. Windows Defender detected it but did not detect the trojan that it also installed.

    Indeed, the risky is real

  2. Cae wrote on :

    “I using Linux, I’m safe, because I’m using openjdk” — I hoped :)

    Firefox “automatically” block me but was unblocked “automatically” again.

    Am I imagining things?

    1. decoder wrote on ::

      No, I think you are right. The block on Linux covered icedtea (openjdk) shortly and was adjusted then to exclude it. You might want to check the original bug report on the block for details :)

  3. Kim Ludvigsen wrote on :

    “to encourage them to upgrade”

    You didn’t really do that. You bewildered a lot of users and you broke the system for a lot of users.

    If you wanted to encourage to an upgrade, you would have had a clear message that said that the user’s version was vulnerable from an active threat. You would have told the user that a new version was available, and finally you would have had a link to the page where they could get said new version.

    You did neither of this.

    And then comes the problems with blocked versions that shouldn’t have been blocked, and errors that prevented others from ignoring the block.

    “Thanks to the various people involved in getting the proper blocks in place so quickly”

    No need to thank the people that panicked or didn’t think this through. Hopefully they will learn from this before the last user switch to Google Chrome or other browsers.

    1. decoder wrote on ::

      Hello Kim,

      > You didn’t really do that. You bewildered a lot of users and you broke the system for a lot of users.

      If you are referring to the initial hard block, it was not intended but a regression from a second bug that caused the block to be temporarily non-overridable (except by disabling the blocklisting mechanism) until we fixed the issue. We’re sorry for that but mistakes happen and this has been fixed quickly (and the fix is automatically synced after 24 hours).

      > If you wanted to encourage to an upgrade, you would have had a clear message that said that the user’s version was vulnerable from an active threat.

      Which is what this page says, isn’t it? https://addons.mozilla.org/en-US/firefox/blocked/p80

      > You would have told the user that a new version was available, and finally you would have had a link to the page where they could get said new version.

      That is only linked indirectly from the block page I just linked, I agree. We could add a link to plugin check on those block pages and clearly state when there is an update available (the plugin check page will then send you into the right direction for getting the update).

      > And then comes the problems with blocked versions that shouldn’t have been blocked, and errors that prevented others from ignoring the block.

      If there is stuff blocked that shouldn’t be blocked (which I am not aware of), please post it in the bug. The Java version landscape is pretty scattered across OSes.

      > No need to thank the people that panicked or didn’t think this through.

      This was thought through, there was just a bug with the initial block that was not recognized immediately (and I’m pretty sure there will be a post mortem to find out why it was not recognized). Would you still think it wasn’t thought through if the block had been a soft-block in the first place?

      I also don’t think the reaction was panicked, the numbers of infections on Mac clearly show that time is critical in such a situation (the Flashback infections number is constantly rising).

      1. Kim Ludvigsen wrote on :

        > If you are referring to the initial hard block

        No, I was able to override the block. The hard block is one of the things I referred to in my “And then comes” (the Ice Tea problem is the other) . Those things happens, but it is not good, and perhaps with some more time to test, they wouldn’t.

        > Which is what this page says, isn’t it? https://addons.mozilla.org/en-US/firefox/blocked/p80

        I did not see that page. If there was a link to that page in the message box, it was not very clear. And certainly not one that the average Mr. Smith would find.

        What the message box should have done is something like this:

        [Warning logo] There is a serious vulnerability in your Java plugin. A new version is available and you should upgrade or turn off Java to avoid getting your computer compromised. [link]More about the problem [/link]

        1. I want to upgrade, [Link to upgrade]please help me do so[/link].
        2. I want to turn off Java (some web content may no longer work).
        3. I will take the risk and keep my old Java (not advised).

        > This was thought through

        If it was thought through, then the people thinking should get a new job. They probably thought that it was thought through, but it wasn’t. I am sure you will come to that conclusion in the post mortem. Read the comments in http://blog.mozilla.org/addons/2012/04/02/blocking-java/ and that is just some of the nerdy users. Some of them with a lot of seats.

        In Denmark we all use Java for online banking. The banks have had serious problems with user not being able to use online banking. What do you think those users will do? And what do you think the bank will tell them to do?

        And a footnote. Yes, my Java was too old, and it shouldn’t have been. I am a bit ashamed about that. I thought Sun pushed updates “live”, hence I was not aware my version was too old, as I never say no to update.

        The message box did not make me any wiser. It was not until I asked in the forum of MozillaDenmark, that I learned of Sun’s update practice, then I checked the version number and then I upgraded.

        1. decoder wrote on ::

          > No, I was able to override the block.

          Ok, so you are not arguing about the block but how it looks like I assume? (+ the issues you mentioned later, e.g. IcedTea, which has been fixed quickly as well).

          > I did not see that page. If there was a link to that page in the message box, it was not very clear.

          I just checked how it looks like on Windows. The message box that pops up does not seem to contain the link, but it says that the plugin has been deactivated because of a security problem. The UI there could be improved and that is already being done right now (see Security Roadmap at https://wiki.mozilla.org/Security/Roadmap , first entry).

          The link I mentioned is in the Addons/Plugins Menu, where you can reactivate Java. But I agree that it should be moved to the main box (+ a link to plugin check which gives you the direct update path), but I believe this is already being worked on as we speak here.

          You are also free to help. Mozilla is an open community and we depend on everyone to try and make things better all the time.

          > In Denmark we all use Java for online banking. The banks have had serious problems with user not being able to use online banking.

          I can understand that this caused problems for people that were not on the newest version. But I personally would prefer my online banking not working until I figured out what’s wrong, vs. my computer being infected with malware (and the article hopefully outlines that this is *not* a theoretical scenario but happening all over the world right now).

          > Yes, my Java was too old, and it shouldn’t have been. I am a bit ashamed about that. I thought Sun pushed updates “live”, hence I was not aware my version was too old, as I never say no to update.

          I don’t know about the Sun (now Oracle) update policy as I use OpenJDK. But the update for Sun JDK has been out since February, and I also got that update automatically in a VM I have (just checked it).

          1. Kim Ludvigsen wrote on :

            > Ok, so you are not arguing about the block but how it looks like I assume?

            Yes, looks – and more important information and functionality.

            > but it says that the plugin has been deactivated because of a security problem

            That is simply not good enough. It has to tell people how they can solve this problem: by updating Java. Otherwise the users (at least in Denmark) will not be able to use their online banking with Firefox. Meaning they will change to another browser. Guess which Java version that browser will use.

            That means that the users are not any safer – and they are not using Firefox.

            > but I believe this is already being worked on as we speak here.

            That sound good, no reason to make this mistake again.

            > You are also free to help.

            I can not code, I am only a translator.

            > But I personally would prefer my online banking not working until I figured out what’s wrong, vs. my computer being infected with malware

            I choose my online banking over security. The sites I usually visit do not use Java, except my bank.

            But many will do as you, and that is what caused a lot of problems here, because the users lost their online banking and several other important sites. We have a national system where Java is used for login for banking, governmental sites and more.

            > I don’t know about the Sun (now Oracle) update policy

            I haven’t checked, but I have been told that they update once a month, and if the computer is not online at the update time, it will try again a month later. That would certainly explain why I didn’t see any messages about a new version.

            1. decoder wrote on ::

              > I choose my online banking over security. The sites I usually visit do not use Java, except my bank.

              That is one of the fatal assumptions people make. Of course most of the other sites do not use Java *regularly*. But when they are hacked/infected with Blackhole, then they *will* use Java, but you will not see it. You can also use Java in a hidden way on any website and that’s exactly what exploiters do. So there is absolutely no security gain my only browsing to websites that don’t use Java.

  4. FlashBlocklist wrote on :

    http://www.adobe.com/support/security/bulletins/apsb12-07.html

    “Adobe recommends users of Adobe Flash Player 11.1.102.63 and earlier versions for Windows, Macintosh and Linux update to Adobe Flash Player 11.2.202.228. ”

    Please blocklist all Flash Player versions older than 11.2.202.228. You did it for Java, it’s time to do it for Flash.

    1. decoder wrote on ::

      > Please blocklist all Flash Player versions older than 11.2.202.228. You did it for Java, it’s time to do it for Flash.

      Just because there is a recommendation and a possible security vulnerability, that doesn’t mean we should immediately blocklist something without further investigation.

      We did it for Java for the reasons described in this article (and a very important factor was that there is an exploit in-the-wild and actively being used). I don’t know of any such exploit for the mentioned Flash version.

  5. jmdesp wrote on :

    Hi,
    I think the layman’s part that’s missing from your message is something in the line of “Zeus is a trojan that specializes in the stealing of your online banking identifiers”.

    I wouldn’t be surprised if there was a Zeus module dedicated to the capture of those danish bank identifiers that sound like a perfect target for an evil doer, but it needs to be said that Zeus uses java here only to get on your computer, and once it’s there can steel any kind of identifier, java using bank or not.
    There’s even a module to proxy all the attackers request through your computer in case your bank checks with ip address the request come from, to run it through further scrutiny when it doesn’t match the usual address.

    However Kim Ludvigsen still has a point that it would have been better to direct users to update their java install, since many have two browser installed, so can, and will, go back to IE when Firefox fails to do their on-line banking.

    1. decoder wrote on ::

      > I think the layman’s part that’s missing from your message is something in the line of “Zeus is a trojan that specializes in the stealing of your online banking identifiers”.

      Yes, that information is surely useful for people that are not familiar with the purpose of the ZeuS trojan, thanks for mentioning :)

      > However Kim Ludvigsen still has a point that it would have been better to direct users to update their java install, since many have two browser installed, so can, and will, go back to IE when Firefox fails to do their on-line banking.

      He certainly has a point, and I agreed with that before. The blocklisting UI needs more work and that is already known and recognized as a problem. Very soon, we will also have a click-to-play mechanism that might make some blockings obsolete.

  6. gied wrote on ::

    Personally, I think it would be great if banks themselves would block access with unsafe Java versions. If the version is unsafe, and there is an active exploit, then PC should not be used for online banking. Period. The same should be with other technologies used to access online bank that can be verified during the session.