MSIE DHTML Edit Control Cross Site Scripting Vulnerability
Note: This vulnerability as well as many more can be seen at
http://freehost07.websamba.com/greyhats/
MSIE DHTML Edit Control Cross Site Scripting Vulnerability
[Tested]
IEXPLORE.EXE file version 6.0.2900.2180
MSHTML.DLL file version 6.00.2800.1400
Microsoft Windows XP Home SP2
[Discussion]
I appologize for my previous vulnerability (longnamevuln) which, through
default sp2 settings, would be quite useless :). However, I'm sure that this
will make up for it.
While looking at the popup block killer by http-equiv, I became interested in
the dhtml edit control. I had a gut fealing that more could be done than simple
popup forcing. So I looked into it and surely enough, I did find something. For
the first time (afaik) since sp1, we can, without user interaction (which I
hate btw), inject script into a page that doesnt belong to us :).
While I don't exacly know the specifics of the dhtmled.ocx control, I believe
it uses a lot of the same code from old versions of internet explorer. That
might explain why it acts so similarly to internet explorer. Through my
testing, I only found one way to navigate to a page using the dhtml edit
control: make it run code to 1) specify its window name, then 2) open( ) a page
using its new name as the target parameter. This will grab the page and display
it in the control. After this, the control is still accessible by its parent,
even Script functions. execScript is what I use to directly inject javascript
into the control.
SP2 puts extremely heavy security on the javascript: and vbscript: protocols,
apparently rendering them useless for hacking attempts. However, there are
still plenty of ways to make a target run script. Hehe this is just like to
good ol' days of sp1 :)
The example opens http://google.com in the dhtml edit control and attempts to
show the location.href and document.cookie of the page in a message box.
Example at http://freehost07.websamba.com/greyhats/abusiveparent.htm