COMMAND
MS Internet Explorer
SYSTEMS AFFECTED
MSIE 5 & 4.x
PROBLEM
Juan Carlos Garcia Cuartango found following. Microsoft delivers
with IE 5 an Active X control called "DHTML Edit control Safe for
Scripting for IE 5". In Juan's opinion this control IS NOT SAFE
AT ALL. He has 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
Let's 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 Juan has
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. Juan has asked his 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 we know this is the first time a hole is
"SIGNED". MS has released an "dhtmed.cab" file as an ActiveX
component signed by Microsoft, anybody can distribute this file
and the victim will only see a message telling him that the
component is "Microsoft signed", one trusts MS, everybody who
trusts 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 to MS documentation a CODEBASE parameter must be
explicited in the OBJECT "object" to download the component.
Affected Software Versions:
- Microsoft Internet Explorer 5 on Windows 95, Windows 98, and
Windows NT 4.0.
- Microsoft Internet Explorer 4.0 on Windows 95, Windows 98 and
the x86 version of Windows NT 4.0. Internet Explorer 4.0 on
other platforms, including the Alpha version of Windows NT 4.0,
is not affected.
DHTML Edit Control delivered with MSIE 5 can read user files. 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).
SOLUTION
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 Microsoft did find a cross domain security
violation in the DHTML edit control which MS will revoke, fix,
and release.
3) Internet Explorer has a mechanism in place which allows MS 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\InternetSettings\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.
Customers who are potentially affected by the vulnerability should
evaluate the degree of risk that this vulnerability poses to their
systems and determine whether to download and install the patch.
The patch can be found at
http://www.microsoft.com/windows/ie/security/dhtml_edit.asp