I found that opening a new window, saving a reference to opener in Math, and then enumerating the window object with for..in in a setTimeout just as the server redirect fired caused a crash rated...

I found that a sandboxed window could escape its sandbox by triggering a file download (.zip, .exe, .wmv, etc.) and then calling history.back(). After the back navigation, the page loaded without...

After Win8 Release Preview re-enabled javascript: URLs in sandboxed iframes (having disabled them in Win8 Consumer Preview), I found that Flash's getURL method could reach a named sandboxed window...

I found that loading a cross-origin URL inside a sandboxed iframe and then setting window[0].location to a javascript: URI gave the attacker script execution in the iframe's context with access to...

I found that loading an MHTML file inside a sandboxed iframe using the mhtml: protocol prefix, and then navigating the inner iframe twice to the target URL, bypassed the X-Frame-Options: DENY or...

I found that injecting elements into a window before its server redirect and caching the document.links collection caused a crash when the cached collection was accessed after the redirect, as...

Setting an mhtml: prefix on the current URL via history.pushState and then opening a new window caused a null pointer dereference in KERNELBASE!StrCmpCW during urlmon's redirect security check,...

I found that pushing a redirect URL into an iframe's history with pushState, reloading to complete the redirect, then calling history.back() on the top window left the iframe appearing to belong to...

I found that in IE10 Metro, navigating a fully sandboxed iframe to an MHTML file caused the MHTML content to open in the top window rather than stay contained in the iframe. This bypassed the sandbox...

I found that an evil page could trick touch-screen users who performed the back swipe gesture (moving a finger right to go back) by creating an oversized horizontally-scrollable container with the...

I found that when an iframe used a <meta http-equiv="refresh"> tag to navigate itself to about:blank, the resulting about:blank inherited the domain of the parent page rather than the iframe's own...

In IE10 Metro, navigating to a new URL briefly showed the address bar so the user could see where they were going. I found that using location.reload() with a server-side redirect to a different URL...

I found that an onunload handler could replace the page's content and then freeze the browser thread using a synchronous XMLHttpRequest to a never-responding server endpoint. This left the address...

I found another variant of the document.all caching technique, this time using window.open rather than a modeless dialog. Saving a reference to document.all from a newly opened window before its...

I found that msSetPointerCapture combined with setCapture inside an iframe continued delivering pointer events — including mouse coordinates and click events — even when the user's pointer was...

Calling msSetPointerCapture on an element and then destroying that element via outerHTML = '' caused a crash when the user moused over any scrollbar afterward. The fault occurred in...

Appending a script element with innerText set to a value into a document created via document.implementation.createHTMLDocument("") caused a crash in...

I found that using history.replaceState to point the current history entry at a redirect URL, then calling location.reload(), caused IE10 to load the redirect target while preserving the original...

I found that using history.pushState to inject a redirect URL into the navigation history, followed by history.go(0) to reload, caused IE10 to render the redirect target using the previous page's...

I found that repeatedly reloading a Flash object via innerHTML in a tight onkeypress loop caused a crash in Flash11f rated PROBABLY_EXPLOITABLE. Each keypress replaced the DOM with a new Flash object...

I found that pushing a server-redirect URL pointing at blob: into the history stack with history.pushState, then reloading with history.go(0), caused a crash rated EXPLOITABLE in...

I found that blob URLs created by the parent page could be sent to a sandboxed iframe via postMessage, and the sandboxed iframe could load them as image sources and even read the pixel data via...

I found that creating a blob with HTML content that referenced an HTC behavior (style="behavior:url(1)") and then navigating to it via a server redirect caused a crash in...

Passing "blob:" as the URL to showModalDialog() opened an invisible modal window — one that was present but not rendered — making the entire browser unusable until the process was killed.

Building on the blob-redirect technique, I found that using an invalid content type string (like "INVALID") when creating the blob caused a crash rated PROBABLY_EXPLOITABLE when the server redirected...

Blob URLs were not supposed to be usable as iframe src or browser navigation targets — they were intended only for images, scripts, CSS, and workers. I found that this restriction could be bypassed...

I found that if window.open("javascript:1", "_self") was called inside an iframe while an error notification dialog was pending — and the parent simultaneously destroyed that iframe — IE10 crashed...

I found that setting document.designMode = "Off" inside an iframe before a server redirect triggered a convenient reload, and that ActiveXObject("Microsoft.XMLHTTP") created during that window...

I found that if a cross-origin redirecting iframe used createPopup().document.write() on the parent, the resulting popup's URL became that of the iframe's post-redirect origin. Since the popup's...

I found two related issues in how modal/modeless dialogs handled returnValue and the external object across cross-origin redirects. The first allowed cooperative cross-origin sharing — the opener...

I noticed that saving a reference to document.all from inside a modeless dialog, before the dialog's page redirected to a different origin, preserved cross-origin access to the redirected document....

I found that a window reference stored inside a native JavaScript object like Math survived a cross-origin server redirect. The key insight was that storing a reference in a plain variable did not...

Creating an htmlFile ActiveX object, refreshing its document, and then triggering a document.open(); document.close() pair via an injected image error handler inside a setTimeout caused a crash rated...

Injecting an iframe that immediately redirected, and then calling a non-existent method inside that iframe via execScript after the redirect completed, caused a stack buffer overrun...

By capturing an XMLHttpRequest object from a newly opened window before the window redirected to a different domain, the cached XHR reference retained the ability to make requests in the context of...

Opening a new window that would soon redirect, injecting an iframe into it, creating a createPopup from that iframe, and then calling setInterval from the popup's window caused a crash after the...

IE10's URL.createObjectURL() generated Blob URLs with insufficient randomness. Image blob URLs were readable by any domain in the same window — including cross-origin iframes. The only protection was...

Creating a Blob URL in the main page and then spawning a Web Worker that sent an XHR to any blob URL — even just "blob:" — caused IE10 to crash.

Calling document.normalize() on a complex DOM in IE10 Preview 4 caused a crash. The crash was found while a W3C spec page loaded and called the method as part of its own script.

When loading an XBAP file, IE requests it twice: once to verify the MIME type and once as an argument to PresentationHost.exe. If the server returns a different content type on the second request,...

Opening a new window that loaded non-HTML content (feeds, Flash, XAML, etc.) and immediately setting designMode on its document caused a crash — reliably on IE9 and intermittently on IE10.

This finding built on an existing technique for escaping Low Rights IE (LoRIE) by abusing vsjitdebugger.exe — the Visual Studio just-in-time debugger — which accepts a binary path as a command-line...

The IE10 sandbox could be applied not just through the sandbox HTML attribute but also via the X-Content-Security-Policy HTTP header. This bypass worked by capturing the new window's document object...

Loading a Flash file from a different domain inside an iframe — where the Flash called GetURL with a javascript: target — and then reloading the main page twice caused an exploitable crash in IE8....

The security="restricted" attribute on an iframe is meant to prevent script execution inside it. But if a link inside the restricted frame opens a new window, and that new window calls...

Setting document.designMode = "On" from inside an HTC behavior file caused IE10 to crash.

This technique allowed spoofing the address bar of any website that had at least one iframe. By opening the target site in a new window, hijacking one of its iframes using Flash's GetURL to point it...

Opening and closing the document from a textarea's onkeypress event caused IE10 to crash on the first keystroke.

This was an interesting multi-step sandbox escape. A sandboxed iframe opened a new window, navigated it through a chain that included loading non-renderable content (RSS feed, SWF, MHT, ZIP, etc.),...

With both allow-scripts and ms-allow-popups set, a sandboxed iframe could open a new window and then use that window's opener.parent.location to execute JavaScript in the parent's context —...