First, the bad news. Once again, Mac users are at risk due to a flaw in Java, similar to the one that enabled the Flashback Trojan. Even worse, there isn’t (yet) a patch to fix that vulnerability. But don’t worry: This time around, there’s good news for Mac users: Thanks to changes Apple has made, most of us are likely to be safe from this threat.
That said, although you likely aren’t at risk today, it is clear that Java still represents one of the biggest, most persistent security problems facing users of all operating systems. So I recommend you consider implementing the precautions suggested below.
What happened
On Sunday, August 26, security vendor FireEye published information about a new Java attack that used a previously unknown Java vulnerability. The attack, which originated from China, affected the latest version of the Java Runtime Environment (Java 7, version 1.7). The attack comes through your Web browser when you browse to a malicious site and allows an attacker to silently take complete control over your computer.
After FireEye’s initial post, details about the vulnerability quickly became public and exploits taking advantage of it appeared in multiple attack tools. Further research by security vendor Immunity Inc. indicated that the active exploit actually took advantage of two separate unpatched Java vulnerabilities (what we, in the industry, call zero-days).
The exploit for the first vulnerability was quickly added to the BlackHole exploitation kit—one of the most widely used malicious hacking tools. The exploit is also now available as an attack in the Metasploit penetration-testing framework, which is freely available and favored by script kiddies and security professionals (myself included) throughout the world.
At this time, Oracle—which inherited Java when it acquired Sun Microsystems—has not commented on the exploits, although we now know that the company knew about the vulnerabilities since April and was planning to release a patch in its October update. Only time will tell if the company will break its quarterly patch cycle and release an emergency update sooner. (My money is on early release.)
In summary, we have at least two exploitable vulnerabilities affecting anything running the latest version of Java, both are being used in active attacks, and one is bundled with one of the most popular bad-guy toolkits on the market (BlackHole) and a very popular (and free) security testing tool. You can’t patch either one.
It’s the very definition of “bad”.
Why most Mac users aren’t at risk
All that said, there are two reasons why Macs are less at-risk than people on other platforms, despite being easy to exploit if the right conditions are in place.
The first, and most important, reason is that relatively few Macs are running the vulnerable version of Java. Any operating system running JRE 1.7 is affected, but the attack doesn’t work against JRE 1.6. That last one is the version that Mac users have installed (assuming they use Java at all).
The only way to update from Java 6 (1.6)—the last version supported by Apple—to Java 7 is by manually downloading and installing it from Oracle. And apparently few Mac users have done so: For example, according to a representative of Crashplan, the online backup service that uses Java for its client app, none of that company’s users (who must have Java installed) are using the vulnerable version.
The second reason you don’t have to worry, even if you do have Java 7 installed, is that Apple by default disabled Java applet support in Web browsers in its most recent Java security update. Starting with OS X 10.7 Lion, Java isn’t installed by default anyway. And even if you do turn on Java, OS X will turn it off again if you don’t use it for a while.
Many users do install Java for websites or applications (like Crashplan) that require it. But, again, even if you did install Java, the odds are very, very good that you aren’t running a vulnerable version.
What you should do
There are two simple ways to check to see if you’re vulnerable to this latest threat.
The first option is to run the Java Preferences app (/Applications/Utilities/). On the General tab it shows the version of Java you have installed. If it says you’re running Java SE 7, and if the Enable Applet Plug-in and Web Start Applications option is checked, you are exposed. If it says Java SE 6, or if that applet option isn’t checked, you’re safe.
You can also check your version by opening Terminal and typing java -version. This time you want to make sure the response isn’t 1.7. If it is, don’t be too alarmed; you can’t be exploited if you don’t also have that browser support turned on in the Java Preferences app.
If you are vulnerable, immediately uncheck that Enable Applet Plug-in and Web Start Applications option in the Java Preferences app. Doing so isn’t a perfect defense, but it does prevent malicious websites from exploiting you. (
You could still be tricked into downloading an exploit that you would run manually.)
Using the Java Preferences application is more reliable than disabling Java in your browser since it blocks it from all browsers at once. This allows you to still use Java on your Mac, but without the risk of being infected through your web browser.
The safest way to keep using Java
If, like me, you still need to use Java in your web browser, I recommend the following steps. They will reduce your risk, and I recommend them as an ongoing security practice even if you aren’t on the vulnerable version of Java. Because, to be honest, these Java attacks aren’t about to slow down anytime soon.
First, manually disable Java in your Web browsers. Even if you turned it off in Java Preferences, this will keep it from running if you ever change that setting (which we are about to do). In Google Chrome type chrome://plugins in the address bar and click the link to disable Java. In Safari, go to Safari > Preferences and uncheck Enable Java on the Security pane. In Firefox go to Tools > Add Ons > Plugins and uncheck Java Plug-In.
Next, re-enable Java applet support in the Java Preferences application (or wait for your Mac to automatically prompt you the next time you need it).
Third, pick a secondary browser that you never normally use and re-enable Java in it. For example, I use Chrome as my primary browser, and I disabled Java in it. I almost never use Firefox, but I still have it installed and Java is enabled in it. This protects me as I browse around the Web. (I also use Safari for development testing, so I keep it disabled on that). Whichever browser you choose as your secondary one, you should use it only when you know you need to use Java and you are going to a website you know. For me, I mostly need Java for presenting webcasts, so when I hit a site I must use that requires Java, I use my backup browser.
Disabling Java in your day-to-day browser and having a second browser for Java needs isn’t perfect, but it does offer a lot of protection. It’s easier to remember than installing a tool like NoScript which blocks Java on individual pages, but which many non-techie users find cumbersome. (I actually run it in Firefox, as another layer of protection, but I’m a raging security geek).
Another option is to access Java sites only from inside a virtual machine. I run VMWare Fusion () (and sometimes Parallels Desktop []) and frequently use Windows virtual machines for visiting those non-Mac-compatible websites I sometimes need for work (again, usually old webcast systems). I keep a baseline snapshot of my virtual machines, and revert to those after any risky activity.
We dodged a bullet
For once, being a software version behind worked to the advantage of Mac users, and nearly no Mac users are really at risk from the latest Java exploits. But, as we’ve seen with Flashback and this recent attack, Java remains a prime target. Thus I’d recommend that all users protect themselves, even if you aren’t currently at risk. Disable Java if you don’t need it, turn it off in your browsers if you don’t need it there, or only use it under controlled circumstances if you don’t have a choice.
Rich Mogull has worked in the security world for 17 years. He writes for TidBITS and works as a security analyst through Securosis.com.