Date: Wed, 24 Mar 1999 12:11:09 +0100 From: Juan Carlos Garcia Cuartango 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 DHTMLE Clipboard vulnerability

DHTML Editor Clipboard vulnerability

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. 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.


To see the demo "copy" some text (from any application) and click the button below :

The box below  is a Input Text Area Box your clipboard text data should be here

The box below is "DHTML Edit Control Safe for Scripting for IE 5" 

The script making public the clipboard is very simple :

function getcb()
{
dh.DOM.body.innerHTML="";            // clear body
dh.execCommand(5032);                     // paste
S1.value = dh.DOM.body.innerText;   // copy to text area
}

Back to DTHMLE Vulnerabilities

Created by Juan Carlos Garcia Cuartango


Visitors since Mar 22 Aņo del Seņor de 1999

Last update Mar  24  Aņo del seņor de 1999

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

The  DHTML Editor cross-frame hole

 

The box in the righ is an DHTML Edit Control Safe for scripting.
It shows a form loaded from a diferent domain (www.angelfire.com).
Click the button below and I will fill the form and submit It.

Dont worry about the message displayed. It is only a demo.

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).

Back to DTHMLE Vulnerabilities

Created by Juan Carlos Garcia Cuartango


Visitors since March 22 Aņo del Seņor de 1999

Last update March 23 Aņo del seņor de 1999

 

------------------------------------------------------------------------------- Date: Thu, 25 Mar 1999 10:06:01 -0800 From: Harry Goodwin 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 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 = ; ; ... ; CODEBASE; ; ... ; 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 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 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 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 = ; ; ... ; CODEBASE; > ; > ... ; 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