Microsoft: The IE threat is real, and so is the fix

Though it remains uncertain if anyone has actually been affected by an Internet Explorer browser flaw that has made national news headlines, Microsoft's tactic today is to treat it as though it's real, and respond the same way.

In a statement to BetaNews early this morning, the author of a Microsoft security vulnerability team blog post yesterday said his team is aware of exploit sites that are trying -- if not yet successful -- to discover the exploit for a problem that the company discovered in response to reports of an active exploit in the field.

"Unfortunately, there are a bunch of active exploit sites right now attempt to exploit Windows XP and Windows Server 2003 users running IE7," the team's Jonathan Ness told BetaNews. "We don't make the decision to release out-of-cycle lightly and we will only do it for confirmed, unpatched vulnerabilities under active attack. If you're familiar with either the Metasploit framework or the milw0rm.com hacker Web site, both have proof-of-concept exploit code available that have been picked up by bad guys to install malware on unsuspecting browsers."

Ness updated us on the basic profile of the problem which is due to be addressed by an out-of-cycle patch, which is still scheduled for distribution early this afternoon, East Coast time. The company's initial security bulletin advised workarounds which centered around ActiveX controls, which led many -- including BetaNews -- to believe that IE's original system for enabling remote code execution, was at the heart of the problem.

But since that time, new information had prompted Microsoft and third-party security companies to back away from that initial profile. As it turns out, today's out-of-cycle patch, Ness told us this morning, will not address an ActiveX-related issue, but rather a related issue which security firm Secunia had tried to explain in an early bulletin of its own.

"This vulnerability is actually not related to ActiveX controls leaving code in memory," Ness wrote. "This vulnerability is a very real memory corruption issue in the way MSHTML.dll parses XML-based data-binding objects."

The MSHTML dynamic link library is indeed responsible for exposing COM interfaces to ActiveX controls; over the years, Microsoft's multitude of fixes to ActiveX-related security flaws have directly patched this library. But one of its overall purposes is to help bind graphic objects that appear in Web pages to data objects in memory. ActiveX controls are one way to achieve this kind of binding; but more recently, data providers such as ADO.NET have enabled MSHTML to act as a data source object (DSO) for data tables that can be expressed in HTML or XML.

For XML-based binding, developers add elements to their HTML pages that list explicitly where the XML for bound data begins and ends. These elements are referred to as XML data islands; and it is here, according to Ness, where exploitation is a possibility. ActiveX could be involved, but it doesn't have to be; and in this particular instance, apparently, it is not ActiveX that is at the center of the danger.

Ness advises IT departments not yet implementing the patch that they can avoid the chance of exploitation by disabling XML island functionality in their browsers.

"We initially considered suggesting customers unregister or ACL msxml3.dll to block attempts to exploit the vulnerability," Ness wrote on his team's blog yesterday. "Blocking msxml3.dll system-wide turned out to break lots of stuff. However, disabling only the XML Data Island CLSID is enough to prevent msxml3.dll from loading only for IE for known attacks. Also, from our testing, it appears that not very many Web sites use the XML Data Island functionality, so this is our least intrusive workaround...and it works on all supported platforms."

---

1:15 pm EST December 17, 2008 - When we asked Microsoft's Jonathan Ness for clarification of whether Microsoft believed there were active attempts to exploit the problem that's the subject of today's out-of-cycle fix, he responded that his team now has reason to believe that one Windows user out of every 500 may have been exposed to a Web site which may contain real, active, non-imaginary, verifiable exploits for this problem.

"I am telling you that there are active exploits and real Windows users are unfortunately being infected with malware," Ness told BetaNews this afternoon. "I think probably the most public Microsoft acknowledgment of this has come from our malware protection center blog. If you read the top two postings there, you'll see a detailed breakdown of exploits by detection name, by country of impacted user, and even a startling statistic: They estimate 0.2% of Microsoft Windows users worldwide have been exposed to websites containing exploits for this vulnerability. Each of those users running IE7 on either Windows XP or Windows Server 2003 will have gotten infected, unfortunately."

Usually, Microsoft's PR teams are told to mitigate the damage by emphasizing the limits of its possible spread, he went on to say. "But once every couple years when one of these 'big ones' hit, we are quick to point out that unfortunately real users are getting infected."

We then asked Ness whether he felt it was fair for the press, including major TV outlets, to characterize this problem as an Internet Explorer "design flaw."

"The press I have seen call it a 'coding flaw,'" he responded. "Not sure if that is splitting hairs but I think of 'design flaws' as 'flaws in design' -- that is, poorly thought out design. Contrast that with 'coding flaws' where the design was solid and an engineer who implemented the design perfectly while using safe coding practices would not have introduced any vulnerabilities. This was a case of poor memory handling. The fix was made to not accidentally reference freed memory. The original design of data binding objects remains.

"I don't see this as a part of an evolution of malicious exploitation about preventative coding," Ness continued. "It was just sloppy memory management."