[whatwg] Storage mutex and cookies can lead to browser deadlock

My recollection is that we prohibit worker access to cookies for exactly
this reason (WorkerGlobalScope does not expose a "cookies" attribute).
-atw

On Wed, Aug 26, 2009 at 2:05 PM, Jens Alfke <snej at google.com> wrote:

> 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 pages
> that use cookies. Assuming the worker thread never exits, the 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?
>
> ?Jens
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090826/e844048c/attachment.htm>

Received on Wednesday, 26 August 2009 14:11:30 UTC