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 ------------------------------------------------------------------------------- Date: Fri, 26 Mar 1999 06:39:23 -0800 From: David LeBlanc 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 = ; ; ... ; 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? 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 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 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 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 ] DHTMLE vulnerabilities

The  DHTML Editor file access hole

 

The box in the right is an DHTML Edit Control Safe for scripting. It will be used to read a file from your computer.

Type a file name (if left blank I will display your c:\config.sys file)


Click and wait few seconds

Last update April 20 Aņo del seņor de 1999

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