The panic over this month's wave of targeted, zero-day attacks against Google, Adobe, and other companies is over. Microsoft has released a security update for Internet Explorer that patches the underlying vulnerabilities, and everyone can breathe a sigh of relief.
But what does this episode say about Internet Explorer? I've seen several pundits argue that Internet Explorer is inherently unsafe. I think they're overreacting. Yes, there is a case to be made for using a different browser, especially one with a lower market share that is targeted less frequently than Internet Explorer. (And if you're too impatient to read this entire post, then skip to the last page for that discussion.) But it's also true that switching browsers is a small part of a comprehensive, defense-in-depth security strategy.
One thing's for certain: Changing browsers isn't a magic bullet, and it might not have made a difference in this case, as I explain in this post.
First things first: How do I protect myself from becoming a victim of this exploit?
Regardless of which version of Internet Explorer or Windows you're using, you should install today's Cumulative Security Update for Internet Explorer (described in KB978207 and Microsoft Security Bulletin MS10-002). This update should be delivered automatically via Windows Update or Windows Software Update Services.
You should also turn on Data Execution Prevention, a feature which prevents code execution from data pages in memory (technical details for the Windows XP family are here, for Windows Vista and 7 here). DEP is on by default in Internet Explorer 8. To enable DEP on Windows XP or Windows Vista with IE6 or IE7, use the Fix It tool on the MS10-002 advisory page.
So, exactly what happened in this case?
The public does not know the full details of what happened. Various reports and analysts have published conflicting reports with a lot of speculative analysis. A January 12 report by Verisign's iDefense security outfit blamed the attacks on an Adobe PDF vulnerability. That report was retracted two days later, although many news stories based on that inaccurate report have not been corrected.
Some key questions have not been answered--or, in some cases, even asked: why, for example, was Google vulnerable to an attack using the outdated Internet Explorer 6? It's reasonable to assume that an outdated browser with known security issues would be used in a lab environment at Google, but this exploit was successful because someone was using IE6 for general-purpose browsing while connected directly to Google's network. Other reasons for the general dearth of hard facts? There's an ongoing criminal investigation with international diplomatic repercussions. Many security professionals are reluctant to disclose details that might help the bad guys with future attacks. And, perhaps most importantly, there is an understandable desire on the part of victims to avoid embarrassment and damage to their reputation by disclosing details. Microsoft was originally made aware of this vulnerability in August 2009 and confirmed its severity in September 2009.
If you want to read more, you can start with the official statements from Google and Adobe. The original Microsoft Security Advisory (979352) has been replaced with Microsoft Security Bulletin MS10-002 and an accompanying Knowledge Base article (KB978207). Microsoft's security bulletin specifically thanks five companies for "working with Microsoft security researchers and providing details of the targeted attacks." The five organizations listed are Google, Adobe, McAfee, MANDIANT, and the French Government CSIRT (CERTA).
A report by George Kurtz on McAfee's Security Research Blog contains the most detailed independent discussion of the issue. McAfee reports that they are "working with multiple organizations that were impacted by this attack as well as the government and law enforcement" and claim to have "analyzed several pieces of malicious code that we have confirmed were used in attempts to penetrate several of the targeted organizations."
Did Microsoft take too long to issue this patch?
The original disclosures from Google and Adobe were published around the beginning of January. Microsoft had completed its investigation and released a patch less than three weeks later. That would be an impressively fast turnaround if the early January date was the first they had heard of this vulnerability. According to Ryan Naraine at ThreatPost, however, Microsoft was originally made aware of this vulnerability in August 2009 and confirmed its severity in September 2009. The fix delivered today was scheduled for release in the normal Patch Tuesday update on February 9 and was accelerated after this attack. The companies that were targeted are no doubt wondering why this fix wasn't available earlier. Had it been released on the second Tuesday of November or December, it's possible that these attacks would not have been so effective.
If the victims of this attack had been using Firefox or Chrome, this would never have happened, right?
It's possible that the attackers targeted particular victims because they were using IE6. The victims in the current wave of attacks were targeted, presumably by criminals or spies who knew exactly what they were doing. In a targeted attack, victims are picked out because they have access to valuable information and can provide access to sensitive parts of their company's network. It's possible that the attackers targeted particular victims because they were using IE6. However, the bad guys could also have used malicious PDF files to do their dirty work, as was the case in a similar wave of targeted attacks in July 2009. They could also have used vulnerabilities in other software. In fact, the McAfee report suggests that might have been the case in this instance:
While we have identified the Internet Explorer vulnerability as one of the vectors of attack in this incident, many of these targeted attacks often involve a cocktail of zero-day vulnerabilities combined with sophisticated social engineering scenarios. So there very well may be other attack vectors that are not known to us at this time.
Mozilla has issued multiple security updates for Firefox 3.5 addressing memory corruption vulnerabilities similar to those used in this case (two examples are here). Mozilla Security reported 34 Critical security advisories in 2009, defining Critical as those that "can be used to run attacker code and install software, requiring no user interaction beyond normal browsing."
Although Chrome is widely praised for its sandboxing approach to security, it's still vulnerable to attacks. One such vulnerability in Google Chrome 3.0, reported last October within days of its release, was triggered by a buffer overflow and could "allow execution of arbitrary code in the Google Chrome sandbox." Two vulnerabilities in Google Chrome 2.0, currently listed as unpatched, reportedly "can be exploited to execute arbitrary HTML and script code in a user's browser session." Secunia reports that four other Critical vulnerabilities in the then-current version of Google Chrome were disclosed and patched between June and August 2009.
But the victims would have been really safe if they had used computers running OS X, right?
Again, not necessarily. It is true that there are very few public exploits that target OS X users, mostly because their numbers are so relatively small. A sufficiently motivated attacker who is aware of an unpatched vulnerability can take over any system, including a Mac. But in a case like this, where the attackers identified specific targets and created custom exploit code to attack those targets, it certainly would have been possible in December 2009 to compromise a system running OS X 10.6 with all security updates. Security Update 2010-001, released by Apple earlier this week, contained fixes for the following vulnerabilities:
- A buffer overflow exists in the handling of mp4 audio files. Playing a maliciously crafted mp4 audio file may lead to an unexpected application termination or arbitrary code execution.
- Multiple issues exist in the Adobe Flash Player plug-in, the most serious of which may lead to arbitrary code execution when viewing a maliciously crafted web site.
- A buffer overflow exists in Image RAW's handling of DNG images. Viewing a maliciously crafted DNG image may lead to an unexpected application termination or arbitrary code execution.
A sufficiently motivated attacker who is aware of an unpatched vulnerability can take over any system, including a Mac. That was proven in dramatic fashion in the 2009 installment of the PWN2OWN competition at CanSecWest, where Charlie Miller successfully compromised a fully patched Mac in seconds (he had also successfully taken over a Mac in 2008). According to ZDNet's Ryan Naraine, Miller summarized his experience as follows: "It took a couple of seconds. They clicked on the link and I took control of the machine."
The security bulletin says IE7 and IE8 are vulnerable. Doesn't that mean all versions of Internet Explorer are equally insecure?
Absolutely not. Many analysts who aren't experienced at decoding security bulletins are confused by the terms vulnerability and exploit. A vulnerability means that a section of code has a flaw that can potentially lead to a security issue. But turning a vulnerability into a working exploit is more difficult. Security features in other parts of the operating system can prevent an exploit from working properly. If you must use IE6, the safest way to do so is in a virtual machine, with security settings for the Internet zone set to High and Active Scripting disabled. In this case, the exploit worked particularly well under IE6 running on Windows XP, but two additional security features (Microsoft refers to these as mitigations) made the exploit much more difficult to execute using later browser versions and Windows Vista or Windows 7.
- Address Space Layout Randomization (ASLR), a security feature introduced in Windows Vista and also used in Windows 7, moves data into randomly selected locations in memory. An attacker who aims at a buffer overflow on a system running Windows XP can predict the address location where the overflow data will wind up and can then try to execute it. Using ASLR, the attacker has to guess at the location and has only a 1 in 256 chance of being right.
- Data Execution Prevention (DEP) takes advantage of a security feature in modern CPUs to mark pages in memory with the NX (No Execute) bit. If a buffer overflow is able to force code into a page that is intended for data, the code will not execute. Security researchers have been hammering on DEP for several years with limited success, but in the meantime it has nullified entire classes of exploits.
In this instance, one researcher was reportedly able to work around DEP and create a proof-of-concept exploit using IE8 on Windows XP. However, Microsoft researchers report that the same exploit did not work on Windows Vista and Windows 7 because of ASLR. Based on published, if someone at one of the targeted companies was running Internet Explorer 7 or 8, they were not affected by this attack.
If I'm currently using IE6, what should I do?
Please switch to a more modern browser if possible. The best way is to upgrade to a more recent version of Windows. Neither Windows Vista nor Windows 7 will run IE6. If you must use IE6, be aware of its inherent vulnerabilities and take extra security precautions.
Is there a safe way to continue to use IE6?
If you must use IE6, the safest way to do so is in a virtual machine, with security settings for the Internet zone set to High and Active Scripting disabled. Add the list of known sites that require IE6 for access (including applications running on your corporate intranet) to the Trusted Sites zone. Use the virtual machine only for access to those sites, and do everyday web browsing in a more modern and secure browser.
So, should I stop using Internet Explorer?
That's a choice only you can make, and you shouldn't let anyone use fear or exaggeration to scare you into making a hasty or ill-considered decision.
In my opinion, if you don't have overriding compatibility or support issues, there are several good reasons to prefer alternative browsers such as Firefox or Google Chrome to any version of Internet Explorer. For starters, both Mozilla and Google have generally been faster at releasing updates to security issues than Microsoft. If it's true that Microsoft knew about this issue for more than four months before delivering a fix, that's a big argument against trusting IE.
And, right or wrong, security by obscurity is real. Although other browsers have serious vulnerabilities, Internet Explorer is the one with the target on its back. Those other, less popular products might be targeted someday, but at least for now most in-the-wild exploits simply don't work on anything except Internet Explorer.
If you do decide to switch default browsers, just remember that doing so is only one relatively small step in a comprehensive security program. And if you have assets that bad guys are likely to target, your security challenges are enormous, and the stakes are getting higher every day.