[tor-bugs] #10773 [Torbutton]: TorBrowser Noscript plugin does not block HTML5 audio/video tags

Thu Jan 30 07:27:57 UTC 2014

#10773: TorBrowser Noscript plugin does not block HTML5 audio/video tags
-------------------------------------------------+-------------------------
 Reporter:  gilidula                             |          Owner:
     Type:  defect                               |         Status:  new
 Priority:  normal                               |      Milestone:
Component:  Torbutton                            |        Version:  Tor:
 Keywords:  html5 torbutton noscript torbrowser  |  0.2.4.19
  audio video                                    |  Actual Points:
Parent ID:                                       |         Points:
-------------------------------------------------+-------------------------
 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

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10773>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online