[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #10773 [Torbutton]: TorBrowser Noscript plugin does not block HTML5 audio/video tags
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs