User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36 Steps to reproduce: Using the PoC tool attached, I registered ~300 service workers each pointing to a single JS file (worker source) but with max_length scope initiated. 1. Host qsw.js attached in comment 1 in the same origin as PoC html file. 2. Open PoC, wait for the tab title to be 400+ 3. Close firefox (try exiting normally or force it to shut using task manager. 4. Attempt to open Firefox, crash occurs. Actual results: The script kept registering service workers and I noticed a lot of memory is being used by firefox. So I closed it, after opening firefox again I get a crash error after a few seconds. https://crash-stats.mozilla.com/report/index/aaefb078-3a83-457b-b359-1c6240180509#tab-details I then thought maybe firefox is opening the same PoC file that has the script (from cache), so I attempted to open firefox in a private window. Same crash appears: https://crash-stats.mozilla.com/report/index/87d6934a-2285-42a5-b052-197280180509#allthreads I also tried to open firefox in safe mode, still crashes. The only thing that worked was creating a new profile and using it. Works on release build as well: https://crash-stats.mozilla.com/report/index/e500156e-7553-4ec0-af25-0ce130180509 Expected results: Limit the number of service workers that can be registered. Limit max size of scope string to URL max size instead.

This is the worker example that should be hosted with the original PoC. Also would like to clarify, the last crash I said it was from a new profile. I ran the PoC steps again on the new profile and it crashed. You can always create a new profile and firefox will work, just not the profile where we spammed service worker registration.

Note sure this needs to be a secure bug. Its hitting a MOZ_CRASH: MOZ_CRASH(IPC message size is too large) We don't chunk the service worker list on startup. If you are using very large scope strings obviously we hit this internal message size limit. This is a DoS/compat/stability issue, but not a security problem. Somewhat related to: https://github.com/w3c/ServiceWorker/issues/1310

Note, this problem will go away once our e10s refactor is complete. We won't need to send the registration list across IPC at all.

Would this bug not fall into the "Persistent DoS attacks that prevent the user from starting Firefox or another application in the future" description from https://wiki.mozilla.org/Security_Severity_Ratings ?

Ah, you are correct.