Site Isolation enables timing attacks against partitioning across simultaneously open tabs
Categories
(Core :: Security, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | disabled |
firefox81 | --- | disabled |
firefox82 | --- | disabled |
People
(Reporter: rniwa, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: privacy, sec-moderate, Whiteboard: [disclosure date 2020-12-08])
Attachments
(1 obsolete file)
In Chrome style site isolation in which each registrable domain's content is put into its own process but shared across tabs / top-level gTLD+1, it’s possible to evade storage partitioning with a timing attack by way of monitoring delays to heart beat signals.
A tracking site may do something like this:
- Fire a timer every 100ms, and check how much time has passed. If there is more than 200ms of delay, start (3).
- When the page that does (1) is loaded, spin while (1) for 300ms. This signals to other instances of (1) that an interesting side channel communication would start. Immediately after this, communicate each binary digit of the unique identifier of the user using varying lengths of delay every 50ms. 20ms delay would imply 0, 40ms delay would imply 1.
- Fire timer every 10ms. Observe delays in (2) to decode the binary numbers.
Let’s go through a concrete example.
- User loads a.com in tab A which loads scripts from tracker.com.
- Spins loop for 300ms per (2).
- Start firing 100ms heart beat timer in (1).
- User loads b.com in tab B with loads the same script from tracker.com.
- Spins loop for 300ms per (2).
- a.com’s tracker.com code notices 300ms delay and transitions into (3)
- b.com’s tracker.com code starts inducing 50ms or 20ms delay to encode user’s identity as b.com identifies.
- a.com’s tracker.com code decodes this. Now a.com and b.com’s identifies are connected on the server side.
There are a few error corrections you need to add in addition to simple (1) ~ (3) to account for things like throttling, GC pause, etc… but with some tweaking this will be a pretty effective side channel.
As long as there is at least one tab alive with a tracker.com's script running, it's possible to keep propagating / sharing this user identity across navigations, thereby defeating the storage bucket partitioning.
Reporter | ||
Comment 1•4 years ago
|
||
I'm reporting this issue on behalf of Apple and the standard 90 day disclosure window applies.
Comment 2•4 years ago
•
|
||
Does "loads scripts from tracker.com" mean having an iframe which loads scripts and iframes sharing the same process, yet not having BroadcastChannel or such between the iframes (because of partitioning)?
Comment 3•4 years ago
|
||
Yeah.
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 4•4 years ago
|
||
Here's a question for you all. I know you haven't shipped site isolation like Chromium yet and Google folks are considering to open their issue open to public. Would that negatively affect your release plans? I've been asked to check up with you all.
Comment 6•4 years ago
|
||
It's fine to disclose this given we're not shipping site isolation or partitioning to release. And it's already effectively public given bug 1646047.
Comment 7•4 years ago
|
||
Making this bug public for the reasons mentioned in comment 6
Reporter | ||
Comment 8•4 years ago
|
||
Chromium issue is: https://bugs.chromium.org/p/chromium/issues/detail?id=1126324
Updated•4 years ago
|
![]() |
||
Updated•1 year ago
|
Description
•