OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
IE 5 security vulnerabilities
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IE 5 security vulnerabilities


  • To: NTBUGTRAQLISTSERV.NTBUGTRAQ.COM
  • Subject: IE 5 security vulnerabilities
  • From: Juan Carlos Garcia Cuartango <cuartangojcMX3.REDESTB.ES>
  • Date: Wed, 24 Mar 1999 12:11:09 +0100
  • Approved-By: Russ.CooperRC.ON.CA
  • Reply-To: Juan Carlos Garcia Cuartango <cuartangojcMX3.REDESTB.ES>
  • Sender: Windows NT BugTraq Mailing List <NTBUGTRAQLISTSERV.NTBUGTRAQ.COM>

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