Opened 6 years ago

Last modified 4 years ago

#10773 new defect

TorBrowser Noscript plugin does not block HTML5 audio/video tags

Reported by: gilidula Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-torbutton
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Software: TorBrowser 3.5.1
Relevant to recent bug: https://trac.torproject.org/projects/tor/ticket/8386

The TorBrowser software design document states:

"Plugins must be restricted
Even if plugins always properly used the browser proxy settings (which none of them do) and could not be induced to bypass them (which all of them can), the activities of closed-source plugins are very difficult to audit and control. They can obtain and transmit all manner of system information to websites, often have their own identifier storage for tracking users, and also contribute to fingerprinting.

Therefore, if plugins are to be enabled in private browsing modes, they must be restricted from running automatically on every page (via click-to-play placeholders), and/or be sandboxed to restrict the types of system calls they can execute. If the user agent allows the user to craft an exemption to allow a plugin to be used automatically, it must only apply to the top level url bar domain, and not to all sites, to reduce cross-origin fingerprinting linkability. "

What this implies, is that software components to the browser should be under scrutiny from a security standpoint. I hold that the audio/video rendering engine of firefox is such a component.

From the design:
"We have verified that these settings and patches properly proxy HTTPS, OCSP, HTTP, FTP, gopher (now defunct), DNS, SafeBrowsing Queries, all javascript activity, including HTML5 audio and video objects..."
Also:
"The adversary simply renders WebGL, font, and named color data to a Canvas element, extracts the image buffer, and computes a hash of that image data. Subtle differences in the video card, font packs, and even font and graphics library versions allow the adversary to produce a stable, simple, high-entropy fingerprint of a computer."
Finally,
"At least two HTML5 features have different implementation status across the major OS vendors: the Battery API and the Network Connection API. We disable these APIs through the Firefox preferences dom.battery.enabled and dom.network.enabled. "

So you have determined that the audio and video object are properly proxied, yet the features conflict with the security requirement. Basically, you have blocked WebGL and several HTML5 subcomponents, for reasons of security and fingerprint-ability, but are not blocking the audio/video tag, which likely has the same issues. It appears your study only included audio/video proxying, and not the security, fingerprint-ability, or data retention requirements.

The audio/video tags are HTML5 tags that allow the loading, streaming, storing, proxying, and playing of rich-media content such as audio and videos. This software is built into Firefox. It is a multimedia engine written in C++ for variety of platforms and shipped with the Firefox code. It is not necessary for browsing. Other researchers have deemed there will be trouble here, with flash you have one player, multiple platforms--here, there will be different implementations in every browser--a zero-day paradise.

The rational is simple: Adobe wrote Flash 10 years ago and there are still 130 vulnerabilities EVERY YEAR, for what amounts to simply a vector graphics/video player! And that is from developers that have feedback from millions of systems and specialize in writing that type of code. I hold that the Mozilla developers do not have the same experience as the Flash developers, and hence will have the same, if not more, vulnerabilities in their implementation of these HTML5 tags. Granted this is a "how many piano tuners are in Chicago" analysis, but it may be valid.

Therefore, I conclude, that the audio/video tags are against the design of the tor browser at this point. Even though the code may be open source, it cannot be deemed to be secure, or even more secure than flash. Yet, Flash/Gnash has not been endorsed/recommended. I do not believe the tor project has the bandwidth to ensure these tags will meet the design at this point.

Therefore, I see that having these components ON by default is a defect.

Here is the relevant diff files:
https://gitweb.torproject.org/torbrowser.git/commitdiff/db11fa55d2a27a01f766bb0c90858381fd9f0c97
https://gitweb.torproject.org/torbrowser.git/commitdiff/94b632f285c92e57dd88af18ede4448d6e1a901c

Child Tickets

Change History (2)

comment:1 Changed 6 years ago by gilidula

At a minimum, please update the design document with a new section on these tags, your research into the security and privacy requirements, vulnerabilities, etc., issues raised in this bug, and rational for allowing it--if that is the conclusion that this comes to. Simply wanting to watch youtube on Tor is novel, but if a security issue, then it should go out (in default settings).

comment:2 Changed 4 years ago by bugzilla

Component: TorbuttonTor Browser
Keywords: tbb-torbutton added; html5 torbutton noscript torbrowser audio video removed
Owner: set to tbb-team
Severity: Normal
Version: Tor: 0.2.4.19
Note: See TracTickets for help on using tickets.