A while ago, apparently angry with Larry Seltzer, I penned a quick write-up on the possible issues with race conditions triggered by asynchronous browser events (such as JavaScript timers) colliding with synchronous content rendering: http://seclists.org/vulnwatch/2006/q3/0023.html This is in principle similar to signal handling bugs. I gave an example of a seemingly exploitable flaw in Firefox (see MFSA2006-59 report for more details), but did mention that other browsers are unlikely to be immune. Today, inspired by Brian Krebs' report on MSIE's stellar track of security response that we all owe to responsible disclosure, I thought it would be a brilliant idea to test MSIE for the same class of problems (they had half a year to take notice of my original rant). Hey, and - no peeking! - guess what happened? A quick demonstration of how MSIE succumbs to such problems would be to prepare an XML file that contains a bunch of nested tags (10-1000 is fine), then display it in IFRAME, repeatedly disrupting the rendering process with a Javascript timer that forces the frame to be reloaded every 50-100 miliseconds or so. After just a couple reloads, MSIE will freeze, then crash in a random manner in the vicinity of msxml3 module. I observed seemingly harmless NULL pointer dereferences, writes to bogus addresses, reads from unallocated memory, and various other signs of memory corruption typical of such race conditions. The exact mode of crash depends on precise timing and the contents of browser memory (previously / concurrently displayed pages, contents of the rest of the document), but this is obviously well within the control of a determined attacker. As such, it is my guess that although (as with all race conditions) this would be fairly hard to exploit remotely in a reliable way, it is within the realm of possibility. A quick "vanilla" but reasonably reliable demo that will probably freeze then crash your browser on a NULL pointer dereference (or sometimes a mangled target pointer on REP MOVSW or something along these lines, if you came there from some other website) can be found at: http://lcamtuf.coredump.cx/iediex/iediex.html ...try using the 'genie.sh' utility provided in the same directory to generate more elaborate test cases that, combined with additional contents of the pages will likely trigger more interesting memory corruption scenarios. /mz
