COMMAND
Internet Explorer exploit via iframe and Document
SYSTEMS AFFECTED
Microsoft Internet Explorer 5.5 and 6.0; prior versions and IE6 SP1 are
not vulnerable.
Note that any other application that uses Internet Explorer's engine
(WebBrowser control) is affected as well (Outlook under the Internet
zone, MSN Explorer, etc.).
PROBLEM
In GreyMagic Security [security@greymagic.com] Advisory [GM#011-IE]
http://security.greymagic.com/adv/gm011-ie/
The <frame> and <iframe> elements may contain URLs in other
domains or protocols, and therefore have strict security rules, which
prevent frames in one domain to access content and information in
another. Microsoft explains the issue in this Cross-Frame Scripting
article -
http://msdn.microsoft.com/workshop/author/om/xframe_scripting_security.asp.
There are several ways to refer to an <iframe>'s (or <frame>)
document in Internet Explorer (assuming <iframe id="oFrameId">):
* oFrameId.document
* document.all.oFrameId.contentWindow.document
* frames.oFrameId.document
* And others..
All these methods are handled correctly by Internet Explorer and
prevent any attempt to access a document that originates from a foreign
domain.
Discussion:
===========
The <iframe> and <frame> elements are really instances of the
WebBrowser control supplied by Microsoft. The WebBrowser control
exposes several potentially dangerous properties by default, which
Microsoft overrides in Internet Explorer.
However, Microsoft missed out on one important property -- "Document",
with a capital "D".
Normally, using "oElement.document" would provide a reference to the
document that owns the current element. The same applies to the
<frame> and <iframe> elements. However, we discovered that when
"oIFrameElement.Document" is used, the returned document is the one
contained inside the frame, and there are no security restrictions in
place to check if it's in a different domain.
This provides free and full access to the frame's Document Object
Model, which allows an attacker to steal cookies from any site, gain
access to content in sites (forging content), read local files and
execute arbitrary programs on the client's machine (script in the "My
Computer" zone).
Both Internet Explorer 5.5 SP2 and Internet Explorer 6 are vulnerable,
but surprisingly this vulnerability does not exist in IE6 SP1. It's
hard to believe that Microsoft actually meant to plug it as IE5.5
remains vulnerable, yet somehow this stray property is now protected.
Exploit:
========
This exploit demonstrates how an attacker may choose to read the
client's "google.com" cookie.
<script language="jscript">
onload=function () {
// Timer necessary to prevent weird behavior in some conditions
setTimeout(
function () {
alert(document.getElementById("oVictim").Document.cookie);
},
100
);
}
</script>
<iframe src="http://google.com" id="oVictim"></iframe>
Demonstration:
==============
We put together four proof-of-concept demonstrations:
* Simple: Reads the client's "google.com" cookie.
* D-Day Console: Automatically load and execute commands on any site.
* D-Day Reading: Read local files by accessing a res:// URL.
* D-Day Execution: Execute arbitrary programs by accessing a res:// URL.
They can all be found at http://security.greymagic.com/adv/gm011-ie/
SOLUTION
Until a patch becomes available either disable Active Scripting or
upgrade to IE6 SP1.