[whatwg] Storage mutex and cookies can lead to browser deadlock
snej at google.com
Wed Aug 26 14:05:52 PDT 2009
I know that one of the design issues with worker threads and local
storage has been how to resolve concurrency issues, and that for this
reason, in the current spec worker threads can't access local storage.
However, there's a scenario under the current spec that doesn't
involve local storage, whereby a worker thread can deadlock the
browser. This is because access to cookies, by workers or the browser
itself, is also subject to that global mutex.
Consider these steps:
1. A worker thread accesses "document.cookie". This causes it to
acquire the mutex (sec. 3.1.3).
2. The thread now performs some long-lasting operation without
exiting. In the simplest case it just goes into an infinite loop.
3. Meanwhile, the user loads a new web page in the browser.
4. The resulting HTTP response contains a Cookie: header. The spec
requires that the browser's loader temporarily acquire the mutex while
updating the cookie (sec. 2.6, item 4).
5. The page-load blocks indefinitely because the worker thread still
has the mutex and never lets go of it.
The result is that the browser becomes incapable of loading any web
only way to recover from this is to quit the browser. A worker thread
like this could very easily be created by a malicious website,
resulting in a DoS attack on the browser. And of course, a merely
poorly-written script could create the same effect without intending to.
I honestly can't think of any safe way of tweaking the semantics of
the existing 'document.cookie' API to make it transactional. :(
Has anyone implemented this portion of the spec yet?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg