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 🙂
kang
wrote on
Cae
wrote on
decoder
wrote on
Kim Ludvigsen
wrote on
decoder
wrote on
Kim Ludvigsen
wrote on
decoder
wrote on
Kim Ludvigsen
wrote on
decoder
wrote on
FlashBlocklist
wrote on
decoder
wrote on
jmdesp
wrote on
decoder
wrote on
gied
wrote on