News

Zero-Day Exploit for IE Flaw Allows Remote Code Execution

• By Scott Bekker
• August 19, 2005

Even as Microsoft's advisory took an unnamed group of security researchers to task for releasing information about the flaw and exploit code publicly, Microsoft itself was scolded by incident handlers at the SANS Institute for providing an infrastructure with IE that allows such attacks in the first place.

The flaw involves a COM object called the Microsoft DDS Library Shape Control, which is provided by the MSDDS.DLL that is installed with Visual Studio 2002 gold and may also be present on systems running Microsoft Office XP Service Pack 3. Customers are not affected if they are using Visual Studio 2002 Service Pack 1, Visual Studio 2003 or Office 2003.

Designed to use a diverse array of ActiveX controls, which are a kind of COM object, Internet Explorer will run any COM object that is referenced by a Web page. COM objects that are not ActiveX controls, such as the Microsoft DDS Library Shape Control, can cause unexpected results.

According to a CERT analysis of the issue, by convincing a user to view a specially crafted HTML document, an attacker can exploit the flaw to execute arbitrary code on the user's machine or cause IE to crash.

What makes the vulnerability especially dangerous is that proof of concept, or exploit code, has been available since Wednesday from an organization called FrSIRT, which stands for French Security Incident Response Team.

Several organizations, including FrSIRT and Secunia, rated the vulnerability "critical" or "highly critical." The SANS Internet Storm Center, in its daily Handler's Diary, warned Thursday, "We feel widespread malicious use of this vulnerability is imminent." Microsoft usually doesn't rate the severity of a flaw until it publicly releases a patch.

SANS noted, however, that Microsoft's publication of several effective workarounds should minimize the threat fairly quickly. Microsoft's workarounds include disabling ActiveX controls, which can break other Web-based applications that use legitimate ActiveX controls; set the kill bit for the component, which has no adverse effects on applications but carries the dangers attendant to editing the Registry; unregistering the component, which will break applications that require the component; or modifying the Access Control List, again potentially breaking applications that have legitimate use for the component.

Microsoft lashed out at unnamed security researchers in its advisory: "Microsoft is concerned that this new report of a vulnerability in Internet Explorer was not disclosed responsibly, potentially putting computer users at risk. We believe the commonly accepted practice of reporting vulnerabilities directly to a vendor serves everyone's best interests."

Microsoft's criticism is apparently aimed at FrSIRT, which itself credited an anonymous source for the vulnerability information. Several organizations, including CERT, identified FrSIRT as the first to go public with the information. However, FrSIRT is not the only security organization providing the exploit code. SecurityTracker, for example, also posted the exploit code in full on its Web site.

Incident handlers at the SANS Institute, who weren't involved in spreading exploit code and who joined Microsoft in helping customers handle the issue, leveled criticism at Microsoft over the underlying problem.

In an "Open letter from the handlers," they wrote, "It merits pointing out that this particular vulnerability really isn't 0-day, it's more like 380-day, as the underlying vulnerability has been around for a long time. Microsoft … [and others] have been recommending that users set "kill bits" on individual ActiveX/COM objects for a year now, as an ultimate fix for the issue."

Pointing to this month's Microsoft security update MS05-038, which sets kill bits for a number of COM objects not intended to be accessed through IE, the handlers wrote, "Have we all forgotten the lessons of taking a default-permit stance with regard to defense? The underlying vulnerability is not that javaprxy.dll (MS05-037) or shell32.dll (MS05-038) or msdds.dll can be invoked from a Web page; the real issue is that the MSIE Renderer, which can be invoked from nearly every Microsoft application (Office, Outlook, …) is allowed to access any object within the operating system without any controls whatsoever."

"There should be a default-deny setting, allowing only a white-list of 'known good' ActiveX objects. Microsoft, this situation demands a more effective and encompassing solution, it needs to be enabled by default, and it cannot afford to wait for [Windows] Vista [and Windows Internet Explorer 7] to be released," the handlers wrote. They did acknowledge that Microsoft offers a few tools for technically-savvy users to harden IE against such attacks.

Click here to view Microsoft Security Advisory (906267).