Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Web Browser)  >   Microsoft Internet Explorer Vendors:   Microsoft
Microsoft IE dhtmled.ocx Lets Remote Users Execute Cross-Domain Scripting Attacks
SecurityTracker Alert ID:  1012584
SecurityTracker URL:
CVE Reference:   CVE-2004-1319   (Links to External Site)
Updated:  Feb 8 2005
Original Entry Date:  Dec 16 2004
Impact:   Disclosure of authentication information, Disclosure of user information, Execution of arbitrary code via network, Modification of user information
Exploit Included:  Yes  
Version(s): 6.0
Description:   A vulnerability was reported in Microsoft Internet Explorer (IE) in the DHTML Edit ActiveX control. A remote user can execute scripting code in arbitrary domains.

Paul from GreyHats Security Group reported that a remote user can create HTML that, when loaded by the target user, will invoke the 'dhtmled.ocx' ActiveX control to inject arbitrary scripting code into a different window on the target user's system.

The HTML can open a window and display the page in the control. The parent HTML window can access scripting functions in the new window via the execScript() function.

A demonstration exploit example is available at:

Impact:   A remote user can execute arbitrary scripting code in an arbitrary domain on the target user's system.
Solution:   No solution was available at the time of this entry.
Vendor URL: (Links to External Site)
Cause:   Access control error
Underlying OS:  Windows (Any)
Underlying OS Comments:  Tested only on Windows XP SP2

Message History:   This archive entry has one or more follow-up message(s) listed below.
Feb 8 2005 (Vendor Issues Fix) Microsoft IE dhtmled.ocx Lets Remote Users Execute Cross-Domain Scripting Attacks
The vendor has issued a fix.

 Source Message Contents

Subject:  MSIE DHTML Edit Control Cross Site Scripting Vulnerability

Note: This vulnerability as well as many more can be seen at

MSIE DHTML Edit Control Cross Site Scripting Vulnerability 

IEXPLORE.EXE file version 6.0.2900.2180
MSHTML.DLL file version 6.00.2800.1400
Microsoft Windows XP Home SP2

I appologize for my previous vulnerability (longnamevuln) which, through default sp2 settings, would be quite useless :). However,
 I'm sure that this will make up for it.

While looking at the popup block killer by http-equiv, I became interested in the dhtml edit control. I had a gut fealing that more
 could be done than simple popup forcing. So I looked into it and surely enough, I did find something. For the first time (afaik)
 since sp1, we can, without user interaction (which I hate btw), inject script into a page that doesnt belong to us :).

While I don't exacly know the specifics of the dhtmled.ocx control, I believe it uses a lot of the same code from old versions of
 internet explorer. That might explain why it acts so similarly to internet explorer. Through my testing, I only found one way to
 navigate to a page using the dhtml edit control: make it run code to 1) specify its window name, then 2) open( ) a page using its
 new name as the target parameter. This will grab the page and display it in the control. After this, the control is still accessible
 by its parent, even Script functions. execScript is what I use to directly inject javascript into the control. 

SP2 puts extremely heavy security on the javascript: and vbscript: protocols, apparently rendering them useless for hacking attempts.
 However, there are still plenty of ways to make a target run script. Hehe this is just like to good ol' days of sp1 :) 

The example opens in the dhtml edit control and attempts to show the location.href and document.cookie of the page
 in a message box. 

Example at


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2019, LLC