Opened 5 years ago

Last modified 4 weeks ago

#13543 new defect

HTML5 media support may lead to fingerprinting

Reported by: cypherpunks Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-fingerprinting, TorBrowserTeam201910
Cc: gk Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I have found out that Tor Browser 4.0 can play videos that older versions of TBB couldn't. It's because the new firefox can load gstreamer plugins into the browser and play mp4 files (inside what I believe to be HTML5 player).
I fear this means that gstreamer is able to connect directly or send sensitive information to the server where the video file is hosted.
If you change "media.gstreamer,enabled" to "false", it prevents gstreamer from being loaded, but it might cause fingerprinting problems.

Any thoughts on this? Should this be enabled? Or maybe change it in later versions.

It could still be used maybe in TAILS, to make vimeo and other websites able to play videos (using gstreamer in a more secure environment).

Child Tickets

TicketStatusOwnerSummaryComponent
#22548closedtbb-teamFirefox downgrades VP9 videos to VP8 when measured performance is not enoughApplications/Tor Browser

Change History (24)

comment:1 Changed 5 years ago by cypherpunks

Component: - Select a componentTor Browser
Keywords: tbb-fingerprinting added
Owner: set to tbb-team

Firefox using several external multimedia frameworks (GStreamer DirectShow WMF OMX Apple's_MP3), which used to playback media files even if browser plugins disabled. Some of them are proprietary software. Even if no interface for some of them to deanon users directly, it's still vector to exploit bugs, which can't be fixed by Tor Browser update.

Yet, it's realistic way to fingerprint users, HTML5 allows to enumerate supported MIMEtypes/codecs. With simple feedback from canPlayType it's possible to detect platform and/or used OS version or used version of external multimedia framework or presence of them at least.

Last edited 5 years ago by cypherpunks (previous) (diff)

comment:2 Changed 5 years ago by mikeperry

Keywords: tbb-fingerprinting-os added; tbb-fingerprinting removed
Summary: Tor Browser 4 loads external pluginsHTML5 media support may lead to OS fingerprinting

I reviewed the coupling for gstreamer and other codecs on Linux, MacOS, and Windows (see content/media in the Firefox source tree), and it appears that the actual networking is performed over nsIChannels, which should be proxied. See #13020. The only exception I found was for Android, where RTSP could be used, which uses UDP and not nsIChannels.

Granted the fact that these codecs are binary may mean that they do all sorts of strange things, so prefs to disable these codecs may still be useful for the security slider (#9387). We already were thinking of disabling everything but WebM and VP8-9 at the high security level there.

As for fingerprinting, OS fingerprinting is the next cliff of fingerprinting issues, and I suspect a lot of things actually allow the OS type to be inferred in various ways. I think trying to solve the OS fingerprinting issues before dealing with more serious things that actually allow more detailed inference about the computer may be a mistake, especially when it comes at the cost of functionality. Hence I'm trying to break out the fingerprinting issues that likely only yield the OS type into their own sub-tag (tbb-fingerprinting-os).

That said, if different people's computers may have different versions of these codecs installed because of third party software or OS localization/version differences, and that fact is still detectable, then this may be a more serious concern.

comment:3 Changed 5 years ago by cypherpunks

We already were thinking of disabling everything but WebM and VP8-9 at the high security level there.

Media plugins and stuff should be disabled by default like browser plugins disabled now. It's not about slider, or slider should to have negative levels that will allow to shoot in the foot, which happens if flash plugin enabled.

comment:4 Changed 5 years ago by cypherpunks

OP here:

Mike, thank you for the info (missed that ticket, sorry!).
However two questions:

  1. What do you mean "binary"? Gstreamer is free software. Are you talking about the codecs installed in the system itself? I would assume using a distro like Debian or Trisquel (which use only free software) would aleviate this issue.
  1. So, could this be used in security/privacy manner? Or we should maybe leave it to TAILS? I ask because since TAILS provides a more "fail close" environment, maybe it could be left enabled there but disabled in native TBB. Opinions? Should hackers go and watch redtube porn videos on tor browser bundle with this, or will their momma know their into asian chicks?? :P

comment:5 Changed 5 years ago by gk

Cc: gk added

comment:6 Changed 5 years ago by mikeperry

Skruffy pointed out that http://html5test.com/ is a useful test to inspect various aspects of html5 support at a glance. Much of that is based on browser feature set, but there are a few things that are OS dependent there, too.

comment:7 Changed 5 years ago by cypherpunks

https://www.mozilla.org/en-US/security/advisories/mfsa2015-31/

Security researcher Aki Helin reported a use-after-free when playing certain MP3 format audio files on the web using the Fluendo MP3 plugin for GStreamer on Linux. This is due to a flaw in handling certain MP3 files by the plugin and its interaction with Mozilla code. This can lead to a potentially exploitable crash.

comment:8 Changed 2 years ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

comment:9 Changed 11 months ago by omg

Keywords: tbb-fingerprinting-os-version added; tbb-fingerprinting-os removed

Version also.

comment:10 Changed 10 months ago by gk

Keywords: tbb-fingerprinting-os added; tbb-fingerprinting-os-version removed

comment:11 Changed 7 months ago by gk

Keywords: tbb-fingerprinting added; tbb-fingerprinting-os removed
Priority: MediumHigh

FWIW: we should use this bug as well to think about possible issues with/solutions for the MediaCapabilities API as well. https://bugzilla.mozilla.org/show_bug.cgi?id=1461454 is the tracking bug on Mozilla's side. Research by tjr suggests that this is indeed not only an OS fingerprinting vector, thus raising prio. See the thread on tbb-dev for more details: https://lists.torproject.org/pipermail/tbb-dev/2019-January/000946.html

comment:12 Changed 7 months ago by gk

Summary: HTML5 media support may lead to OS fingerprintingHTML5 media support may lead to fingerprinting

comment:13 Changed 6 weeks ago by gk

Keywords: ff68-esr TorBrowserTeam201910 tbb-9.0-must added

comment:14 Changed 5 weeks ago by acat

Keywords: TorBrowserTeam201910R added; TorBrowserTeam201910 removed
Status: newneeds_review

For review: https://github.com/acatarineu/tor-browser/commit/13543

This should skip checking for hardware acceleration or performing a benchmark when RFP is enabled, and always set smooth = true and powerEfficient = true instead. I only modified one case, since AFAIK it's the only one where the value smooth or powerEfficient depend on hardware capabilities.

The intent was to implement the solution mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1461454#c6.

comment:15 Changed 5 weeks ago by tom

I think it would be better to put the RFP behavior in a more obvious place:

an else if case here: https://searchfox.org/mozilla-esr68/source/dom/media/mediacapabilities/MediaCapabilities.cpp#285

containing

MediaCapabilitiesInfo(true, true, true)

comment:16 Changed 5 weeks ago by gk

Keywords: TorBrowserTeam201910 added; TorBrowserTeam201910R removed
Status: needs_reviewneeds_revision

comment:17 Changed 5 weeks ago by acat

Keywords: TorBrowserTeam201910R added; TorBrowserTeam201910 removed
Status: needs_revisionneeds_review

Revised: https://github.com/acatarineu/tor-browser/commit/13543+1.

Out of curiosity, is there a reason why MediaCapabilitiesInfo(true, true, true) is better than MediaCapabilitiesInfo(true, true, false), or is it just that we had to pick one? In Linux (true, true, false) seems to be more common, but maybe the other is more found in Windows and Mac?

comment:18 Changed 5 weeks ago by tom

Sorry; I don't have an informed opinion on that - I'll defer to you. I just wanted the RFP case to be clearer.

comment:19 Changed 5 weeks ago by acat

Ok, let's leave it as it is then.

comment:20 in reply to:  19 Changed 5 weeks ago by gk

Keywords: TorBrowserTeam201910 added; TorBrowserTeam201910R removed
Status: needs_reviewnew

Replying to acat:

Ok, let's leave it as it is then.

Cherry-picked to tor-browser-68.1.0esr-9.0-2 (commit 990e3caf34672b64f30db79f585903b8ce4f88d6).

I wonder whether we should pick (true, true, false), though, instead. Leaving this ticket open to decide this.

comment:21 Changed 4 weeks ago by acat

Keywords: TorBrowserTeam201910R added; TorBrowserTeam201910 removed
Status: newneeds_review

I thought a bit more, I don't have a very strong opinion in favor of one or another, basically because I'm not sure how this API will be used by websites. But I think it may be better to be conservative and say it's not power efficient while it actually may be than the opposite. For smooth the same reasoning might apply, but *I think* it's not so common to find cases where the returned info is (true, false, false) (I did not find those in a couple of home machines, although it may be possible in slow machines).

Since we have to pick one, I'm voting for (true, true, false): https://github.com/acatarineu/tor-browser/commit/13543+2.

comment:22 in reply to:  21 Changed 4 weeks ago by gk

Keywords: TorBrowserTeam201910 added; TorBrowserTeam201910R removed
Status: needs_reviewnew

Replying to acat:

I thought a bit more, I don't have a very strong opinion in favor of one or another, basically because I'm not sure how this API will be used by websites. But I think it may be better to be conservative and say it's not power efficient while it actually may be than the opposite. For smooth the same reasoning might apply, but *I think* it's not so common to find cases where the returned info is (true, false, false) (I did not find those in a couple of home machines, although it may be possible in slow machines).

Since we have to pick one, I'm voting for (true, true, false): https://github.com/acatarineu/tor-browser/commit/13543+2.

Looks good to me. I cherry-picked your fixup to tor-browser-68.1.0esr-9.0-3 (commit 084aa467fafc8aee4c2fbb57e872096386aca775).

I guess on hindsight I should have put the MediaCapabilities related work in a proper child ticket and treat this one as just a meta/parent one. We should review the HTML5 fingerprinting scope *here* and then file *child* tickets from now on. If we think we are good after review, let's close this bug.

comment:23 Changed 4 weeks ago by gk

Keywords: tbb-9.0-must removed

comment:24 Changed 4 weeks ago by gk

Keywords: ff68-esr removed

The ff68-esr specific bits are gone.

Note: See TracTickets for help on using tickets.