UXSS: Mixing Document Mode Across Tridents Using MHT

This one surprised me. By embedding an MHT file that forced a lower document mode (IE7 emulation) and then placing a cross-origin iframe inside it, I found that errors triggered when the inner frame tried to access top were delivered to the top window instead of staying local. That let the top window hijack the error handler’s caller and read the cross-origin iframe’s DOM.

<!-- top window -->
<iframe src="lower_document_mode.mht" width="700" height="240"></iframe>
<script>
window.onerror = function handleError()
{
    xFunction = handleError.arguments.callee.caller.constructor;
    xFunction('alert("document.URL:\\n" + document.URL + "\\n\\ndocument.body.innerText:\\n" + document.body.innerText)')();
    return true;
}
</script>

<!-- try_to_access_top.html (cross-origin, inside the mht iframe) -->
<input type="button" value="alert(top)" onclick="alert(top)" />

The MHT file declared X-UA-Compatible: IE=EmulateIE7, which caused Trident to mix document modes across the frame hierarchy. In that mixed state, an access-denied error from a cross-origin alert(top) call propagated upward into the top window’s onerror handler — carrying a reference to the calling frame’s constructor. From there it was straightforward to eval arbitrary code in the context of the cross-origin frame. My view was that the right fix was to prevent document mode mixing rather than patching the cross-origin leak directly.

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