Open Bug 1544232 Opened 3 years ago Updated 3 months ago

Possible vulnerabilities in allowing unbounded system resource usage for installed service workers


(Core :: DOM: Service Workers, task, P3)






(Reporter: ehsan.akhgari, Assigned: asuth)


(Blocks 1 open bug)


(Keywords: sec-audit)


(1 file)

So this paper is out:

It makes a wide range of claims around possibilities for service workers to consume unlimited system resources in the background, which could be attack vectors for coin mining, ad fraud, click farms, DDoS, etc.

Some of the claims may not be super accurate (eg we don't implement BG sync yet) but it's worth going through it to see if we need to fix anything.

Filing as private for now even though the paper is public.

And also my twitter conversation with Alex Russell:

So, I think our concerns at this point are:

  • Push messages which spawn ServiceWorkers without (current) user interaction. :lina had mentioned there was a quota system in place at the last all hands, and quickly perusing the code, it:

    • Updates the quota based on the last visit time as understood by Places[1].
    • Penalizes quota[2] if a (desktop) notification is not produced by the ServiceWorker in a timely fashion, currently 3 seconds[3].
  • ServiceWorker infinite life extension via postMessage. Currently, any/all extendable events dispatched at a ServiceWorker will reset the idle timer[4]. This is theoretically a problem because It's possible for a ServiceWorker to be woken up by a push and then invoke postMessage at itself or other SW registrations to stay alive forever. It's not a problem for Firefox right now because we don't expose ServiceWorker instances on workers so it's impossible for a ServiceWorker to message itself or any other ServiceWorkers to extend their lives. This means that it would need to be a (potential) Client of the SW who would postMessage it, and these (potential) Clients can already legitimately keep the SW alive. Bug 1113522 tracks exposing ServiceWorker on workers.

    • I believe Chrome addressed this by defining that a ServiceWorker can only grant a life-extension as long as its own. I think they also specifically were seeing two ServiceWorkers extending each others' lifetimes, whereas I think we may
    • That is, the risk is that if a SW can run for at most 5 minutes when receiving a "push" or "fetch" event, and SW "A" received its most recent event 3 minutes ago, it now has 2 minutes left of time budget. If it postMessages SW "B", waking it up, "B" would be granted a max of 2 minutes of time budget. Not 5.

1: called from
2: called from after a timeout
4: ResetIdleTimeout() called by called by

This is a good set of conversations to have in public, since the issue is known and if anything people will want to know that we've investigated it. If we find a specific new and unknown problem we can file separate security defect bugs.

Group: core-security
Type: defect → task
Keywords: sec-audit
Priority: -- → P2
Blocks: 1113522
Priority: P2 → P3
Assignee: nobody → bugmail

The ServiceWorkerManager needs to grow a mechanism to lookup ServiceWorker
instances based on the client id we assigned to them. This would be a single
additional map and it could make sense to promote and use the id we expose to
devtools. (However, we definitely would not want to expose the Cache API
cache name as that seems easier for an exploit chain to leverage.)

Depends on D99450

You need to log in before you can comment on or make changes to this bug.