Concurrency strikes MSIE (potentially exploitable msxml3 flaws) Jan 04 2007 10:22PM
Michal Zalewski (lcamtuf dione ids pl) (1 replies)
RE: [Full-disclosure] Concurrency strikes MSIE (potentially exploitablemsxml3 flaws) Jan 04 2007 10:36PM
Larry Seltzer (Larry larryseltzer com) (1 replies)
I hope you're still not angry!

I just tried your demo on IE7. It took a while longer but does seem to
have locked up. Were you looking at IE6 or IE7, and is the behavior any

Larry Seltzer
eWEEK.com Security Center Editor
Contributing Editor, PC Magazine
larryseltzer (at) ziffdavis (dot) com [email concealed]

-----Original Message-----
From: full-disclosure-bounces (at) lists.grok.org (dot) uk [email concealed]
[mailto:full-disclosure-bounces (at) lists.grok.org (dot) uk [email concealed]] On Behalf Of Michal
Sent: Thursday, January 04, 2007 5:22 PM
To: bugtraq (at) securityfocus (dot) com [email concealed]
Cc: full-disclosure (at) lists.grok.org (dot) uk [email concealed]
Subject: [Full-disclosure] Concurrency strikes MSIE (potentially
exploitablemsxml3 flaws)

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:


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

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:


...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.


Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[ reply ]
RE: [Full-disclosure] Concurrency strikes MSIE (potentially exploitablemsxml3 flaws) Jan 04 2007 10:51PM
Michal Zalewski (lcamtuf dione ids pl)


Privacy Statement
Copyright 2010, SecurityFocus