Full Disclosure mailing list archives
RE: Concurrency-related vulnerabilities in browsers -expect problems
From: Larry Seltzer <Larry () larryseltzer com>
Date: Sun, 13 Aug 2006 07:35:23 -0400
"... Larry Seltzer reports from the scene." Film@11 Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.eweek.com/blogs/larry%5Fseltzer/ Contributing Editor, PC Magazine larryseltzer () ziffdavis com -----Original Message----- From: full-disclosure-bounces () lists grok org uk [mailto:full-disclosure-bounces () lists grok org uk] On Behalf Of Michal Zalewski Sent: Saturday, August 12, 2006 12:15 PM To: bugtraq () securityfocus com; full-disclosure () lists grok org uk Cc: vulnwatch () vulnwatch org Subject: [Full-disclosure] Concurrency-related vulnerabilities in browsers -expect problems Good morning, "Fame-hungry sociopath torches cars, finds browser flaws WARSAW, Poland (AP) -- police are on a look out for a local adolescent vandal who continues to terrorize local IT workers in what appears to be a bizzare bid for fame. Larry Seltzer reports from the scene." Well, I just had to do this, forgive me. There seems to be an interesting class of concurrency-related bugs in popular browsers. This is quite similar to signal-handling flaws you might be familiar with: many browser events can be triggered asynchronously, for example using Javascript timers, while some components of the browser are still running. In many cases, a new action might be initiated that interferes with or counters the interrupted (or still executing) task. Problems like this may leave the program in inconsistent state, and later cause double frees or related issues. That usually opens the door to system compromise through careful manipulation of memory contents. The attacks would depend heavily on network latency and jitter, but can be executed. Given that the tip of that iceberg has been probed recently - for example here: http://www.mozilla.org/security/announce/2006/mfsa2006-46.html - I assumed it is now the time to post my older example. A fairly reliable example is when Firefox is interrupted by a Javascript handler while parsing a deeply nested XML document for display. If the browser is then redirected from the script to a new location, the unfinished parsing process is aborted, and all its structures are freed - but these were not left in the expected state by the parser. This is a demo that will usually crash Firefox in a couple of seconds (SEGV on Linux and MacOS, silent crashes on Windows): http://lcamtuf.coredump.cx/ffoxdie.html Have fun! PS. For the easily amused: MSIE loves "<DT><H1 STYLE=width:1px><LI></H1>" /mz http://lcamtuf.coredump.cx/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Concurrency-related vulnerabilities in browsers - expect problems Michal Zalewski (Aug 12)
- RE: Concurrency-related vulnerabilities in browsers -expect problems Larry Seltzer (Aug 13)
- Re: Concurrency-related vulnerabilities in browsers - expect problems Michal Zalewski (Aug 15)
- Re: [VulnWatch] Re: Concurrency-related vulnerabilities in browsers - expect problems Steven M. Christey (Aug 17)
- Re: [VulnWatch] Re: Concurrency-related vulnerabilities in browsers - expect problems Michal Zalewski (Aug 17)
- Re: [VulnWatch] Re: Concurrency-related vulnerabilities in browsers - expect problems Steven M. Christey (Aug 17)