1447935 - Bypasses found for Firefox Tracking Protection

Status: RESOLVED FIXED

(Toolkit :: Safe Browsing, defect, P3)

Description

[Gertjan]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce:

We simulated an extensive set of web mechanisms that initiate cross-site requests to a blacklisted domain, while Firefox Tracking Protection’s strict blocking was enabled. Unfortunately, FTP did not manage to block all cross-site requests to the blacklisted domain. What follows is a list of web mechanisms that were able to bypass this countermeasure.

* AppCache API (caching a resource located on a blacklisted domain)
* Response headers (referring to the blacklisted domain)
   - Link rel=next
   - Link rel=prefetch
* HTML tags (referring to blacklisted domain)
   - <link rel="shortcut icon" href=“…”>
   - <link rel="apple-touch-icon image_src" href=“…”>
* EventSource API (referring to blacklisted domain)
* WebSocket API (opening a new web socket for the blacklisted domain)
* Fetch API, importScripts() used by ServiceWorker (referring to blacklisted domain)


Actual results:

The cross-site requests to the blacklisted domain were not blocked.


Expected results:

The cross-site requests to the blacklisted domain should have been blocked.

Comment 1

[François Marier [:francois]]

(In reply to gertjan.franken from comment #0)
> * AppCache API (caching a resource located on a blacklisted domain)

Tracked in bug 1262339.

> * Response headers (referring to the blacklisted domain)
>    - Link rel=next
>    - Link rel=prefetch
> * HTML tags (referring to blacklisted domain)
>    - <link rel="shortcut icon" href=“…”>
>    - <link rel="apple-touch-icon image_src" href=“…”>

Also see bug 523095.

> * Fetch API, importScripts() used by ServiceWorker (referring to blacklisted
> domain)

Tracked in bug 1437626.

Note that these are likely not just a bypass of tracking protection, but also of Safe Browsing. I'm not sure it's directly exploitable by malware/phishing sites in that case, but it's still something we should fix.

Comment 2

[Steven Englehardt [:englehardt]]

Trackers have used WebSockets to bypass resource blocking extensions (https://www.ieee-security.org/TC/SPW2018/ConPro/papers/bashir-conpro18.pdf). There's nothing specific to TP in the paper, but the same workarounds could be deployed against TP.

Comment 3

[François Marier [:francois]]

Attachment: tpc-paper.pdf

I think we can make this bug public now.

The paper is here: https://wholeftopenthecookiejar.eu/

and has won the Distinguished Paper award at USENIX Security (congrats BTW!). So we can assume that anybody who can benefit from knowing these bypasses already knows about them.

Comment 4

[Gertjan]

Hi, I've done a retrospective analysis of Firefox versions, up until Firefox 76. All issues discussed in the original report appear to be resolved, except for one; the request initiated by the WebSocket API is not blocked by Tracking Protection when directed to a blacklisted domain.

This can be reproduced by simply using the following code to instantiate a WebSocket:

var socket = new WebSocket('https://tracking-domain.com');

Third-party cookies are included in this a request.

Comment 5

[Dimi Lee [:dimi]]

Attachment: Bug 1447935 - P1. CreatePairwiseEntitylist uses loading principal when a channel doesn't have an associated top-level window

loads in appcache doesn't have a top-level window, use loading principal
instead.

Depends on D80185

Comment 6

[Dimi Lee [:dimi]]

Attachment: Bug 1447935 - P2. Use fission-compatible third-party checks

Depends on D80186

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bcf6ab4e4f50
P1. CreatePairwiseEntitylist uses loading principal when a channel doesn't have an associated top-level window r=baku
https://hg.mozilla.org/integration/autoland/rev/0332d1b01f63
P2. Use fission-compatible third-party checks r=baku

Comment 8

[Razvan Maries]

Backed out for perma failures.

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedTaskRun=GnpfGbhbT7-AoMTDPPmbmQ.0&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception&searchStr=windows%2C10%2Cx64%2Cdebug%2Cxpcshell%2Ctests%2Ctest-windows10-64%2Fdebug-xpcshell-e10s-2%2Cx%28x2%29&revision=0332d1b01f63e7c4077a1d24e293b655f126d35e

Log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=309133049&repo=autoland&lineNumber=6475

Backout: https://hg.mozilla.org/integration/autoland/rev/5bb8de53b2ac112dccb3b2d85b1958223c20fd39

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/aecde048367e
P1. CreatePairwiseEntitylist uses loading principal when a channel doesn't have an associated top-level window r=baku
https://hg.mozilla.org/integration/autoland/rev/ce29017fe754
P2. Use fission-compatible third-party checks r=baku

Comment 10

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/aecde048367e
https://hg.mozilla.org/mozilla-central/rev/ce29017fe754