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

Status: ASSIGNED

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

Description

[(no longer active)]

So this paper is out:

https://www.ndss-symposium.org/ndss-paper/master-of-web-puppets-abusing-web-browsers-for-persistent-and-stealthy-computation/

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.

Comment 1

[(no longer active)]

See this too:

https://www.ics.forth.gr/dcs/index_main.php?l=e&c=735

Comment 2

[(no longer active)]

And also my twitter conversation with Alex Russell:

https://twitter.com/ehsanakhgari/status/1117148181287133187?s=19

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

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: https://searchfox.org/mozilla-central/rev/1b2636e8517aa48422ed516affe4d28cb7fa220a/dom/push/PushRecord.jsm#57 called from
https://searchfox.org/mozilla-central/rev/1b2636e8517aa48422ed516affe4d28cb7fa220a/dom/push/PushService.jsm#755
2: https://searchfox.org/mozilla-central/rev/1b2636e8517aa48422ed516affe4d28cb7fa220a/dom/push/PushService.jsm#818 called from
https://searchfox.org/mozilla-central/rev/1b2636e8517aa48422ed516affe4d28cb7fa220a/dom/push/PushService.jsm#714 after a timeout
3: https://searchfox.org/mozilla-central/rev/1b2636e8517aa48422ed516affe4d28cb7fa220a/modules/libpref/init/all.js#53304
4: ResetIdleTimeout() https://searchfox.org/mozilla-central/rev/1b2636e8517aa48422ed516affe4d28cb7fa220a/dom/serviceworkers/ServiceWorkerPrivate.cpp#2036 called by
https://searchfox.org/mozilla-central/rev/1b2636e8517aa48422ed516affe4d28cb7fa220a/dom/serviceworkers/ServiceWorkerPrivate.cpp#2020 called by
https://searchfox.org/mozilla-central/rev/1b2636e8517aa48422ed516affe4d28cb7fa220a/dom/serviceworkers/ServiceWorkerPrivate.cpp#1657

Comment 4

[Daniel Veditz [:dveditz]]

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.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

Attachment: Bug 1544232 - Limit lifetime extension of SWs by SWs to the sender's lifetime. WIP.

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

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

Attachment: Bug 1544232 - Limit lifetime extension of SWs by SWs to the sender's lifetime. r=#dom-workers!

Depends on D180914

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

Attachment: Bug 1544232 - Track the client listening to a registration. r=#dom-workers!

This will enable propagating lifetime deadlines based on the deadline
of the client calling ServiceWorkerRegistration.update in the
subsequent patch.

Note that the data-flow of the Client here differs from
ServiceWorkerContainer::Register propagating the ClientInfo to
ServiceWorkerManager::Register. In that case, the binding samples the
client at call-time and propagates it over the register IPC call rather
than during the construction of the PServiceWorkerContainer actor.
This change in approach is to align with Bug 1853706 wherein we plan to
associate the actors strictly to the global.

Depends on D180914