Attacks/Breaches
1/7/2013
05:06 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%
Repost This

When The 'Fix It' Doesn't Fix It

Microsoft's temporary fix for a new IE zero-day flaw is broken, researchers say, but software giant still recommends applying the fix until patch arrives

The latest Microsoft Internet Explorer zero-day attack and response underscores a dilemma faced by enterprises today: whether to apply a temporary fix or hold out for the real patch of a newly exploited bug. Just days after Microsoft issued an emergency fix for the browser bug and urged affected users to install it, researchers have discovered a way to break it.

Exploit Intelligence researchers studying the vulnerability in Internet Explorer versions 6, 7, and 8 found that they could bypass the fix-it Microsoft issued last week in response to active "watering-hole" attacks exploiting IE 8. IE 9 and IE 10 don't include the bug, which some researchers say is a "use-after-free" vulnerability. Microsoft said the vulnerability allows for remote code execution, and issued the MSHTML Shim Workaround Fix It last week to address it.

"What we discovered is that Microsoft's patch did not account for all the ways in which this vulnerability can be exploited," says Aaron Portnoy, vice president of research for Exodus Intelligence. It took the researchers less than day of reverse-engineering to cheat the fix with an exploit they had written earlier.

[Microsoft last fall issued an interim fix-it tool to protect Internet Explorer browsers from a zero-day vulnerability that has spawned attacks by traditional cyberespionage players out of China. See Multiple Targeted IE Attacks Underway, Microsoft To Release Patch Tomorrow.]

So if the emergency fix is broken, does it make more sense to instead just wait for the promised patch from Microsoft?

Microsoft -- which isn't saying when the patch will be released -- is aware of Exodus' findings, but it is still recommending that users apply the fix. "Customer protection is a top priority for us. We are aware of this claim and have reached out to the group for more information, and continue to actively work on a security update to address this issue," says Dustin Childs, group manager, Microsoft Trustworthy Computing. "Additionally, we released Security Advisory 2794220 to provide customer awareness of the issue affecting Internet Explorer versions 6, 7, and 8, and we strongly encourage our customers to apply the mitigations and workarounds described in the advisory."

Exodus Intelligence's Portnoy concurs that the fix-it is still the best bet until there's a patch. "As of right now, we are unaware of anyone besides ourselves having developed an exploit to demonstrate such a circumvention, so we would encourage users to install the current fix from Microsoft as it is the only patch available that will prevent exploitation of any currently public attacks," he says.

Even Microsoft's Enhanced Mitigation Experience Toolkit (EMET), a free tool that helps prevent exploitation, doesn't stop this attack, Portnoy says. His firm was able to bypass EMET, as well, in its exploit.

But deciding whether to apply a workaround fix in this case is not so black and white. "This seems like a bad fix," says Chris Wysopal, CTO at Veracode. "I would think that a high-risk organization would have the capability of ... going ahead and putting up the fix-it. But I don't think it's a good solution for Microsoft to be building software around [the bug] and people consuming software around it. You have to do all of this work, and it might not be fully fixed because it was rushed out so quickly."

In general, most consumers await Microsoft's auto-update to handle the patching for them, while enterprises have their own Patch Tuesday and out-of-band patching practices, he says. "Now you're asking them to do something else" by applying this temporary fix, Wysopal says. "And on top of that, it can be bypassed."

The obvious question, of course, is why not just upgrade to IE 9, which isn't vulnerable in this type of attack.

"This vulnerability does not affect IE 9, so the best option is to avoid using the vulnerable versions of IE -- 6 through 8," says Exodus Intelligence's Portnoy.

Veracode's Wysopal says an enterprise that has the infrastructure to roll out the fix-it should be upgrading to IE 9. "That's the real fix," he says.

Symantec, meanwhile, late last week confirmed that the IE 8 attacks came out of the so-called Elderwood Group, the infamous cyberespionage operation in China best known for the Aurora attacks that targeted Google, Intel, Adobe, and other major corporations.

This group of attackers has used more zero-day bugs in its attacks than any other, Symantec says.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Kelly Jackson Higgins is Senior Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise Magazine, ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
DarkReadingTim
50%
50%
DarkReadingTim,
User Rank: Strategist
1/8/2013 | 4:16:21 AM
re: When The 'Fix It' Doesn't Fix It
Great story, and a great example of the patch dilemma -- which patch to do first, whether to do the workaround while waiting for the real patch, and how fast the patch needs to be put in place. Readers, any thoughts on how to prioritize?
--Tim Wilson, editor, Dark Reading
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

CVE-2012-1317
Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

CVE-2012-1366
Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

CVE-2012-3062
Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

CVE-2012-3918
Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web