1711084 - Scheme flooding technique for reliable cross-browser fingerprinting

Status: NEW

(Core :: Privacy: Anti-Tracking, defect, P2)

Description

[Konstantin Darutkin]

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

Steps to reproduce:

We made a scheme flooding exploit that allows identifying people cross-browser.
Windows, Linux, macOS are affected. The exploit was tested on 88.0.1.

Demo:
https://schemeflood.com/

Source code:
https://github.com/fingerprintjs/external-protocol-flooding

Actual results:

The basic steps are:

1. Open an additional window (AW) with the window.open method;
2. Navigate the AW to the custom protocol URL (such as slack:// or fb://) with the location.replace method;
3. Check if the same origin policy is enabled for the AW. If the document is accessible, then the application is installed on the computer;
4. Perform 24 tests (steps 2-3) in order to get a 24-bit cross-browser fingerprint based on the installed application data.

Comment 1

[Johann Hofmann [:johannh]]

Thanks for reporting this, we'll take a look. :)

Comment 2

[Simon Mainey]

relevant bugzillas?

• Bug 440892
• Bug 484266
• Bug 1167856
• Bug 1626068

FYI: Nightly vanilla profile, test id'ed 20 items (from 24) "installed", 19 of those 20 are false positives

Comment 3

[Konstantin Darutkin]

(In reply to Simon Mainey from comment #2)

relevant bugzillas?
....
FYI: Nightly vanilla profile, test id'ed 20 items (from 24) "installed", 19 of those 20 are false positives

Custom browser configuration may affect the demo results, however the default setup should work. I tested it on Ubuntu, macOS and Windows.
Bug 1167856 and Bug 1626068 seems relevant

Comment 4

[Simon Mainey]

(In reply to Konstantin Darutkin from comment #3)

Custom browser configuration may affect the demo results, however the default setup should work

False positives and vice versa don't really matter as long as it's stable, but I doesn't seem to be consistent. I stated my quick test was in a vanilla (new) profile, but in reality my nightly was slightly tweaked (with browser.link.open_newwindow.restriction = 0 - more on this below).

new profiles except nightly where I reset the newwindow restriction pref

• for the record, only 1 of these 24 is on my system
• nightly90, beta89, release88: detected all 24
• flip browser.link.open_newwindow.restriction = 0 (as per Tor Browser)
  • this stops the new window trying to hide "offscreen" (although I still see it bottom right tiny window on my secondary monitor)
  • in this mode the fingerprinting attempt becomes very apparent (the new "tab" grabs focus as well) and would scare users away - maybe useful for a targeted attack, but not mainstream IMO
• sanitize cache/data etc; retest
• nightly90: 13 found (only 1 is correct), 11 not found <- this differs from my earlier test: hence I said doesn't seem to be consistent
• beta89: 21 found (only 1 is correct), 3 not found
• stable88: 9 found (all false positives), 15 not found (1 false negative)

tl;dr: the results don't have to be correct, it's picking up entropy from other settings

Comment 5

[Simon Mainey]

although I still see it

that should read, although I still SAW it .. when the pref was default 2

Comment 6

[Anne (:annevk)]

This sounds like a duplicate of bug 1626068, but will mark that as a dependency of this bug for now.

Comment 8

[Konstantin Darutkin]

I’ve made some math based on the database data from the backend script that collects results:
https://github.com/fingerprintjs/external-protocol-flooding/blob/master/packages/backend/src/index.ts

1. So far we have 32009 results among 24276 sessions.
2. 2057 sessions (~8%) have more than 1 unique cross-browser identifier. That probably means the demo worked from the 2nd try or result is inconsistent in general.
3. 2728 results have 0 apps installed and 2221 results have all apps installed. Roughly speaking, the demo does not work in 15.4% of cases.
4. 8774 unique identifiers among 34024 tests. (in average, 4 browsers gives the same ID)

These results are about all browsers in general.

Comment 9

[sworddragon2]

This issue made it into common news so more users (including me) might be have gotten aware of it. Comment #4 implies that this issue appears to be not significantly threatening so I was curious about the result when I did the testcase from comment #0 on my current production profile (Firefox 89.0.2 on Windows 10; permanent private browsing mode enabled; privacy.resistFingerprinting=true; dFPI with disabled exceptions active; other small tweaks - pretty much one would expect on a profile that cares for strong privacy). The simple answer is: Nearly everything detected and non-detected was false - hardly different from claiming the choices being random. More curiously repeating the test immediately resulted in another random result - rendering this test unable here to possibly track me.

On the other hand Firefox has accumulated until now quite a good amount of unresolved privacy/tracking-related issues and most of them will not see a fix in the near- or mid-future. The highest threat I'm currently aware of is tracking via the network identifier on IPv6 networks - as it gives a high and relative stable amount of entropy; it can not be spoofed by simple means; there are no good reliable workarounds (including current implementations of the privacy extensions) as far as I know; fixing it might be the very opposite of being trivial. And at some point we will be all on IPv6 and suffer ultimate tracking - there is no escape in sight :)

Still, if the issue Konstantin reported here allows for easier tracking it should probably be evaluated/fixed. But he also might need to check their testcase again if it is still working fine as this seems to be currently not the case on a high-threat level.

Comment 10

[sworddragon2]

Edit:

(In reply to sworddragon2 from comment #9)

network identifier

I meant device identifier as otherwise it would make not much sense. I still wish you could simply edit your posts here so I could also fix my grammar error in my first sentence (and similar uncommon errors in other posts) that even went unnoticed on an audit before sending :)

Comment 11

[Johann Hofmann [:johannh]]

Quick update that fixing this is on our roadmap, with no ETA yet.

Comment 12

[Frederik Braun [:freddy]]

with bug 1723281 fixed, could you also take this one on, Olli?

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

oh wait, I did something wrong in the testing.

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

I can't reproduce this when following the steps in comment 0. Document is always accessible, whether or not the protocol is supported.
I get "Prevented navigation to “zoommtg2://123213” due to an unknown protocol." in the web console when the protocol isn't supported and
a popup to handle the url if protocol is some supported one.

But obviously https://schemeflood.com/ does still work, so it is doing something a bit different.

Does anyone have a minimal testcase?

Comment 15

[Pier Angelo Vendrame]

Attachment: The patch we use in Tor Browser (based on Firefox 91.9.0 ESR)

In Tor Browser we solved this problem with the patch I have attached (developed by Matthew Finkel).

Comment 16

[Neha Kochar [:neha]]

Lowering severity to S3 as there are multiple other fingerprinting issues as it doesn't fit for a S2.

Comment 17

[Tom Ritter [:tjr]]

(In reply to Pier Angelo Vendrame from comment #15)

In Tor Browser we solved this problem with the patch I have attached (developed by Matthew Finkel).

I applied this to Nightly, but it did not seem to change the browser's behavior.

To Olli's question: I think this is the relevant code (although I didn't check that this is the code actually deployed.) The steps seem to be:

1. Make a window, record the starttime
2. Append an iframe with a url of the target application scheme to the popup
3. wait 200ms (the first time)
4. Await for the popup's load event to fire, record that end time, get the delta. Add the delta+15 to 200, record that as the new wait time
5. If you can access iframe.contentWindow, record it as a positive indicator, otherwise a negative indicator
6. Send the popup to about:blank
7. Repeat 1-6, but use the new wait time instead of 200ms

It does seem like the core test is for iframe.contentWindow, and the timing stuff is really about being able to run it as fast as possible, it's not actually doing a timing attack, it just needs to wait a bit.

Comment 18

[Tom Ritter [:tjr]]

I tried to reproduce the behavior from scratch here: https://ritter.vg/misc/ff/schemeflood.html but I could not get it to work. At the same time schemeflood is doing something that's pretty consistent, so I'll have to debug it...

Comment 19

[Tom Ritter [:tjr]]

(In reply to Tom Ritter [:tjr] from comment #18)

I tried to reproduce the behavior from scratch here: https://ritter.vg/misc/ff/schemeflood.html but I could not get it to work. At the same time schemeflood is doing something that's pretty consistent, so I'll have to debug it...

Okay, I fixed the bugs with it and was able to reproduce it on this page, using any of the methods. I also confirmed that Tor Browser's patch does not fix the issue.

ni-ing smaug to let him know.