Vulnerability Note VU#356600

Microsoft Internet Explorer DHTML Editing ActiveX control contains a cross-domain vulnerability

Original Release date: 05 Jan 2005 | Last revised: 17 Feb 2005


A cross-domain vulnerability exists in the DHTML Editing ActiveX control. An attacker may be able to execute arbitrary script in the Local Machine Zone or read or modify data in other domains. For example, the attacker could execute arbitrary commands with parameters, download and execute arbitrary code, read cookies, spoof content, or modify form behavior.


The Cross-Domain Security Model

IE uses a cross-domain security model to maintain separation between browser frames from different sources. This model is designed to prevent code in one domain from accessing data in a different domain. The Internet Security Manager Object determines which zone or domain a URL exists in and what actions can be performed. From Microsoft Security Bulletin MS03-048:

    One of the principal security functions of a browser is to ensure that browser windows that are under the control of different Web sites cannot interfere with each other or access each other's data, while allowing windows from the same site to interact with each other. To differentiate between cooperative and uncooperative browser windows, the concept of a "domain" has been created. A domain is a security boundary - any open windows within the same domain can interact with each other, but windows from different domains cannot. The cross-domain security model is the part of the security architecture that keeps windows from different domains from interfering with each other.
The DHTML Editing Control

The DHTML Editing Control is a wrapper for the MSHTML editor. It is an ActiveX control that provides the ability to perform text and HTML editing functions. The control is marked "safe for scripting," which means that the DHTML Editing Control could be called from Internet Explorer. The LoadURL method, which is traditionally used to open web page content in the DHTML Editing Control, will only open documents in the same domain as the host page. When used with a certain combination of script commands, the DHTML Editing Control can open the content of an arbitrary web page in any domain, regardless of the domain of the host page.

The Problem

The DHTML Editing Control is vulnerable to a cross-domain violation. When the DHTML Editing Control opens the content from a website, it appears to operate within the security context of that website. While the DHTML Editing Control has the security context of the opened site, the DHTML Editing Control is under full control of the page that hosts it. Working indirectly through the DHTML Editing Control, a website in one domain has the ability to access information in another domain or zone.


By convincing a user to view a specially crafted HTML document (e.g., a web page or an HTML email message), an attacker may be able to execute script in the Local Machine Zone. Script that executes in the Local Machine Zone can be used to download and execute arbitrary code. An attacker may obtain full access to web content in another domain, which may reside in a different security zone. The impact is similar to that of a cross-site scripting vulnerability. This includes the ability to spoof or modify web content, access website information such as cookies, or retrieve data from an encrypted HTTPS connection. For a more detailed description of the impact of cross-site scripting vulnerabilities, please see CERT Advisory CA-2000-02.


Install an update
Install the update referenced in MS05-013. With this update, the cross-domain security model is enforced with the DHTML Editing Control.

Disable the DHTML Editing Control

Disable the DHTML Editing Control by setting the kill bit as described in Microsoft Knowledge Base article 240797. The CLSID for the DHTML Editing Control is:

Note that disabling the DHTML Editing Control may prevent Outlook Web Access (OWA) from functioning properly.

Disable Active scripting and ActiveX

Disabling Active scripting and ActiveX controls in the Internet Zone (or any zone used by an attacker) appears to prevent exploitation of this vulnerability. With ActiveX controls disabled, the DHTML Editing Control will not be instantiated. Instructions for disabling Active scripting in the Internet Zone can be found in the Malicious Web Scripts FAQ. See Microsoft Knowledge Base Article 833633 for information about securing the Local Machine Zone, and 315933 for information about displaying the Local Machine Zone (My Computer security zone) on the Security tab in the Internet Options dialog box.

Note that disabling Active scripting and ActiveX controls in the Internet Zone will reduce the functionality of some web sites. Disabling these features in the Local Machine Zone will reduce the functionality of some programs, including the Help and Support Center in Windows XP.

Install Windows XP Service Pack 2 (SP2)

Microsoft Windows XP SP2 includes a feature called Local Machine Zone Lockdown, as well as other improvements. The Local Machine Zone Lockdown prevents Internet Explorer and several other programs from evaluating script in the Local Machine Zone. While this does not remove the vulnerability, it does help prevent an attacker from executing script in the Local Machine Zone.

Apply the Outlook Email Security Update

Another way to effectively disable Active scripting in Outlook is to install the Outlook Email Security Update. The update configures Outlook to open email messages in the Restricted Sites Zone, where Active scripting is disabled by default. In addition, the update provides further protection against malicious code that attempts to propagate via Outlook. The Outlook Email Security Update is available for Outlook 98 and Outlook 2000. The functionality of the Outlook Email Security Update is included in Outlook 2002 and Outlook Express 6. Outlook 2003 includes these and other security enhancements.

Read and send email in plain text format

Outlook 2003, Outlook 2002 SP1, and Outlook 6 SP1 can be configured to view email messages in text format. Consider the security of fellow Internet users and send email in plain text format when possible. Note that reading and sending email in plain text will not necessarily prevent exploitation of this vulnerability.

Do not follow unsolicited links

In order to convince users to visit their sites, attackers often use URL encoding, IP address variations, long URLs, intentional misspellings, and other techniques to create misleading links. Do not click on unsolicited links received in email, instant messages, web forums, or internet relay chat (IRC) channels. Type URLs directly into the browser to avoid these misleading links. While these are generally good security practices, following these behaviors will not prevent exploitation of this vulnerability in all cases, particularly if a trusted site has been compromised or allows cross-site scripting.

Use a different web browser

There are a number of significant vulnerabilities in technologies relating to the IE domain/zone security model, local file system (Local Machine Zone) trust, the Dynamic HTML (DHTML) document object model (in particular, proprietary DHTML features), the HTML Help system, MIME type determination, the graphical user interface (GUI), and ActiveX. These technologies are implemented in operating system libraries that are used by IE and many other programs to provide web browser functionality. IE is integrated into Windows to such an extent that vulnerabilities in IE frequently provide an attacker significant access to the operating system.

It is possible to reduce exposure to these vulnerabilities by using a different web browser, especially when viewing untrusted HTML documents (e.g., web sites, HTML email messages). Such a decision may, however, reduce the functionality of sites that require IE-specific features such as proprietary DHTML, VBScript, and ActiveX. Note that using a different web browser will not remove IE from a Windows system, and other programs may invoke IE, the WebBrowser ActiveX control (WebOC), or the HTML rendering engine (MSHTML).

Systems Affected (Learn More)

VendorStatusDate NotifiedDate Updated
AvayaAffected-17 Feb 2005
Microsoft CorporationAffected05 Jan 200505 Jan 2005
If you are a vendor and your product is affected, let us know.

CVSS Metrics (Learn More)

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A N/A



This vulnerability was publicly reported by Paul.

This document was written by Will Dormann.

Other Information

  • CVE IDs: CAN-2004-1319
  • Date Public: 15 Dec 2004
  • Date First Published: 05 Jan 2005
  • Date Last Updated: 17 Feb 2005
  • Severity Metric: 35.10
  • Document Revision: 29


If you have feedback, comments, or additional information about this vulnerability, please send us email.