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: - 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 MS, silent crashes on Windows):
Have fun!
PS. For the easily amused: MSIE loves "<DT><H1 STYLE=width:1px><LI></H1>"
/mz
http://lcamtuf.coredump.cx/

Here's another separate issue that typically causes fault on memory access
to website-influenced memory access:

This is separate from the previously presented example (which, remarkably,
also had a tendency to trigger an unrelated call stack overflow due to XML
parsing glitch on some platforms, which caused some confusion - my bad).

Note that because it depends on timing more heavily, it may not work in
the first shot on all computers (though it should).

/mz

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

Here's another separate issue that typically causes fault on memory access
to website-influenced memory access:

This is separate from the previously presented example (which, remarkably,
also had a tendency to trigger an unrelated call stack overflow due to XML
parsing glitch on some platforms, which caused some confusion - my bad).

Note that because it depends on timing more heavily, it may not work in
the first shot on all computers (though it should).

/mz

Here's another separate issue that typically causes fault on memory access
to website-influenced memory access:

This is separate from the previously presented example (which, remarkably,
also had a tendency to trigger an unrelated call stack overflow due to XML
parsing glitch on some platforms, which caused some confusion - my bad).

Note that because it depends on timing more heavily, it may not work in
the first shot on all computers (though it should).

/mz

Some interesting work.

For those who haven't made the connection yet - concurrency issues
probably go far beyond just web browsers. It's a safe bet that *any*
software that's multi-threaded, multi-process, event-based, or
asynchronous could have these sorts of issues. Traditional data
manipulation techniques probably won't be effective in finding them.

In other words - concurrency is a rich area for future research, and web
browser bugs are probably the tip of the iceberg.
- Steve

Some interesting work.

For those who haven't made the connection yet - concurrency issues
probably go far beyond just web browsers. It's a safe bet that *any*
software that's multi-threaded, multi-process, event-based, or
asynchronous could have these sorts of issues. Traditional data
manipulation techniques probably won't be effective in finding them.

In other words - concurrency is a rich area for future research, and web
browser bugs are probably the tip of the iceberg.
- Steve

Thu, 17 Aug 2006, Steven M. Christey wrote:

In other words - concurrency is a rich area for future research

past research, for that matter ;-)

The lesson learned is uh

/mz

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

Some interesting work.

For those who haven't made the connection yet - concurrency issues
probably go far beyond just web browsers. It's a safe bet that *any*
software that's multi-threaded, multi-process, event-based, or
asynchronous could have these sorts of issues. Traditional data
manipulation techniques probably won't be effective in finding them.

In other words - concurrency is a rich area for future research, and web
browser bugs are probably the tip of the iceberg.
- Steve

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

Thu, 17 Aug 2006, Steven M. Christey wrote:
In other words - concurrency is a rich area for future research
past research, for that matter ;-)
The lesson learned is uh
/mz

Thu, 17 Aug 2006, Steven M. Christey wrote:
In other words - concurrency is a rich area for future research
past research, for that matter ;-)
The lesson learned is uh
/mz