Testing navigator.mimeTypes for known names can reveal info and increase fingerprinting risk

I gathered a list of MIME Types from IANA and other sources. Then explicitly used each type to check if navigator.mimeTypes[type] === undefined. I found that I could detect quite a few MIME Types in this way. Including some types that are related to specific application programs and/or peripheral devices.

I maxed the security slider, which disabled Javascript by default and broke the test script. However, after I whitelisted the test script I was able to achieve the same results.

I was testing Tor Browser 5.0.3 for Windows.

Trac:
Username: TemporaryNick

added TorBrowserTeam201510R component::applications/tor browser owner::arthuredelstein priority::high reporter::TemporaryNick resolution::fixed severity::major status::closed tbb-fingerprinting type::defect labels

Can you please attach the script you used?

Or better yet, can you implement it as a mochitest unit test and submit a patch? I think it would be really good for me to start uplifting all of these unit tests to mainline. I figure out a way to make them NOT run by default, but it would be great to have them for testing purposes as I re-factor and uplift other patches.

Trac:
Username: TemporaryNick

MimeTypeDetector.html

Demonstrates detection method using a subset of MIME Types

Trac:
Username: TemporaryNick

I uploaded an example, which tests only the application types listed by IANA. There are other types than can be checked and there are an unknown number of types that aren't registered with IANA.

I think the issue is that when you check for a MIME Type in this way, the browser checks with the OS to see whether the MIME Type has been registered. Which MIME Types are registered depends on which application software and/or drivers the user chose to install. My test results were different on different Windows systems. I was, however, testing with a more comprehensive list than that shown in the demonstration.

I think the place to start may be nsMimeTypeArray.cpp, and what happens when you check for a named item. I found someone talking about this type of issue and approaching it via GreaseMonkey script. They mentioned that websites frequently test for some specific MIME Types, so simply blocking named lookups may not be practical.

I don't know enough to tackle this issue.

Trac:
Username: TemporaryNick

I just tested with an en-US 5.0.3 on Windows 7 and all I get is

navigator.mimeTypes.length not > 0

Did you try with a fresh, unmodified Tor Browser 5.0.3? What Windows version did you use? How can I reproduce your problem if it still persists?

Trac:
Keywords: fingerprinting deleted, tbb-fingerprinting added
Status: new to needs_information

In Tor Browser 5.0.3 on OS X 10.10.5, I can't retrieve the length navigator.mimeTypes.length or list of members navigator.mimeTypes.

But I can query for a member (as TemporaryNick describes).

Can you try the attached script with if (navigator.mimeTypes.length > 0) { and the corresponding brace commented out?

Trac:
MimeTypeDetectorTBB503.html

MIME Type Detector Modified to work with TBB 5.0.3

I attached a modified version that works in Tor Browser 5.0.3 on OS X 10.10.5.

It discovers my Microsoft Office installation. It also discovers my Wireshark installation.

This looks like a fingerprint to me, but I don't have multiple machines to test it on, so I can't be sure.

Good stuff! I thought we already had a defense against this but I could not find anything so far. Arthur: do you have some spare cycles to look at this in October? I fear all the other TBB people are busy with deadline work...

Trac:
Priority: normal to major
Owner: tbb-team to arthuredelstein
Keywords: N/A deleted, TorBrowserTeam201510 added
Status: needs_information to assigned

Trac:
Cc: N/A to brade, mcs

Replying to gk:

Good stuff! I thought we already had a defense against this but I could not find anything so far.

It's interesting that navigator.mimeTypes.length == 0. So one would have thought it didn't have any members.

Arthur: do you have some spare cycles to look at this in October? I fear all the other TBB people are busy with deadline work...

Yes -- I'll try to look at this soon.

Replying to arthuredelstein:

Replying to gk:

Good stuff! I thought we already had a defense against this but I could not find anything so far.

It's interesting that navigator.mimeTypes.length == 0. So one would have thought it didn't have any members.

It seems that a partial anti-enumeration design is in place, but only against positional iteration. (As well as setting navigator.mimeTypes.length to 0, all indexes of the form navigator.mimeTypes[0] return undefined.)

But that doesn't stop lookups using an external list of MIME type names.

Trac:
Severity: N/A to Blocker

(The Severity was set to the default due to dgoulet's Trac changes. I set it to Major to match the previous Priority field.)

Trac:
Severity: Blocker to Major

Replying to teor:

Replying to arthuredelstein:

Replying to gk:

Good stuff! I thought we already had a defense against this but I could not find anything so far.

It's interesting that navigator.mimeTypes.length == 0. So one would have thought it didn't have any members.

It seems that a partial anti-enumeration design is in place, but only against positional iteration. (As well as setting navigator.mimeTypes.length to 0, all indexes of the form navigator.mimeTypes[0] return undefined.)

Unfortunately, the anti-enumeration protection which was introduced in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=757726 was removed in Firefox 41: https://bugzilla.mozilla.org/show_bug.cgi?id=1169945

It turns out that the mimeTypes list in Firefox comes from two sources: (1) plugins and (2) applications installed on the system. I considered writing a fixed spoof list of mimeTypes, but it was not clear to me which mimeTypes, if any, should be included in such a list.

At this point, Tor Browser strongly discourages the use of plugins (and makes them click-to-play). So it probably makes sense to make the navigator.plugins object appear to be empty to content pages and not show any plugin-associated mimeTypes. This might in principle break a site that requires Flash, but as we (and Mozilla) are discouraging the use of Flash, I'm inclined not to spoof the presence of a "Flash" plugin. Especially as spoofing the presence of Flash might prevent a JS fallback on some sites.

For applications, I think it is reasonable to force websites to assume that any file will be downloaded rather than opened by a helper app.

So, given these conclusions about plugins and applications, I decided to make navigator.mimeTypes appear empty to content pages as well. But I'm open to further discussion.

I bound this behavior to the "privacy.resistFingerprinting" pref, which will hopefully make Mozilla more amenable to accepting it.

The following branch has two commits for review: the implementation and a regression test:

https://github.com/arthuredelstein/tor-browser/commits/17207+1

Trac:
Status: assigned to needs_review
Keywords: TorBrowserTeam201510 deleted, TorBrowserTeam201510R added

First round of comments:

1. You probably want to do something like #include "nsContentUtils.h" in nsPluginArray.cpp, too (I wonder how you got it compiled without actually).

2. I don't understand

  // TODO: The following line should be active in Firefox 45
+  // isnot(navigator.mimeTypes.length, 0, "navigator.mimeTypes array should be 0");

.

What does it mean? We don't need that test yet? If so, why not? Or does it mean we can't run that test right now because XXX would break it? If so what fixes this (Do you have a bug number?)? And does it mean we are save for now with respect to leaking the length of the supported MIME types? If I am guessing right, the answer lies in https://bugzilla.mozilla.org/show_bug.cgi?id=757726 which got resolved as WON'TFIX. If that is true could you add a hint about that in the test explaining what is going on?

3. s/prmoise/promise/ in the test

Trac:
Status: needs_review to needs_revision

Replying to gk:

First round of comments:

1. You probably want to do something like #include "nsContentUtils.h" in nsPluginArray.cpp, too (I wonder how you got it compiled without actually).

I wonder that too. Apparently it is included in a header file somewhere. I've added #include "nsContentUtils.h" in nsPluginArray.cpp for clarity.

2. I don't understand {{{ // TODO: The following line should be active in Firefox 45

• // isnot(navigator.mimeTypes.length, 0, "navigator.mimeTypes array should be 0"); }}} .

What does it mean? We don't need that test yet? If so, why not? Or does it mean we can't run that test right now because XXX would break it? If so what fixes this (Do you have a bug number?)? And does it mean we are save for now with respect to leaking the length of the supported MIME types? If I am guessing right, the answer lies in https://bugzilla.mozilla.org/show_bug.cgi?id=757726 which got resolved as WON'TFIX. If that is true could you add a hint about that in the test explaining what is going on?

3. s/prmoise/promise/ in the test

Thanks. I've fixed these things: https://github.com/arthuredelstein/tor-browser/commits/17207+2

Trac:
Status: needs_revision to needs_review

mcs/brade: if you have some capacities left and would have a look at this one, too, that would be grand. We might be able to include that one into the alpha as well then.

Kathy is not here at the moment and I actually have to leave soon too... but I took a quick look and the patch and tests look OK to me.

This looks okay to me and I merged cherry-picked the commits onto tor-browser-38.3.0esr-5.5-2. One question: Is there any reason why you did not add ||ResistFingerprinting() to any AllowPlugins()? I guess only those where you added them are fingerprinting relevant? I wonder if that is going to lead into some confusion though: there may be things doable with plugins if you have fingerprinting defenses enabled (and are allowing plugins) and other things only if you have them disabled. Or are there no such things? I know there are a bunch of users that (need to?) enable Flash but maybe we just don't care about them too much here.

Commit 5ea30524fbf92005f236756646beb77684cd2008 and 5578785b6c12ff62b5a2cdcc3d2f5c9762af6c5c are the ones in question.

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

Replying to gk:

This looks okay to me and I merged cherry-picked the commits onto tor-browser-38.3.0esr-5.5-2. One question: Is there any reason why you did not add ||ResistFingerprinting() to any AllowPlugins()? I guess only those where you added them are fingerprinting relevant? I wonder if that is going to lead into some confusion though: there may be things doable with plugins if you have fingerprinting defenses enabled (and are allowing plugins) and other things only if you have them disabled. Or are there no such things? I know there are a bunch of users that (need to?) enable Flash but maybe we just don't care about them too much here.

I only added ||ResistFingerprinting() to places where information is exposed through the content web APIs. I believe the other functions are only called by Chrome code, so ResistFingerprinting() would always return false.

I think the scope of this ticket is not to disable plugins, but merely to prevent their detection through navigator.plugins. It is in principle still possible to detect plugins by including several of them in a page -- but if we enforce click-to-play, then this is not really a practical attack, I think.

Corresponding Mozilla work: https://www.fxsitecompat.com/en-CA/docs/2016/navigator-plugins-and-mimetypes-will-be-unenumerable/ Mozilla made an exception for Flash because of compatibility problems.

Trac:
Reviewer: N/A to N/A

closed

mentioned in issue #17879 (moved)

mentioned in issue #18159 (moved)

mentioned in issue #18220 (moved)

moved to tpo/applications/tor-browser#17207 (closed)

mentioned in issue tpo/applications/tor-browser#17879 (closed)

mentioned in issue tpo/applications/tor-browser#18220 (closed)