[tor-commits] [tor-browser-spec/master] Reorganize and update the attacks section for the new model.
mikeperry at torproject.org
mikeperry at torproject.org
Mon Apr 28 15:18:47 UTC 2014
Author: Mike Perry <mikeperry-git at fscked.org>
Date: Tue Oct 4 22:22:12 2011 -0700
Reorganize and update the attacks section for the new model.
It was still mostly written towards the toggle model.
docs/design/design.xml | 197 +++++++++++++++++++++++-------------------------
1 file changed, 94 insertions(+), 103 deletions(-)
diff --git a/docs/design/design.xml b/docs/design/design.xml
index 8930820..6c1a806 100644
@@ -173,136 +173,119 @@ performed by malicious agents on the Tor network and at national firewalls.
+ <listitem><command>Read and insert identifiers</command>
-can cause the browser to perform network activity after Tor has been disabled,
-thus allowing the adversary to correlate Tor and Non-Tor activity and reveal
-also allows the adversary to execute <ulink
-url="http://whattheinternetknowsaboutyou.com/">history disclosure attacks</ulink>:
-to query the history via the different attributes of 'visited' links to search
-for particular Google queries, sites, or even to <ulink
-users based on gender and other classifications</ulink>. Finally,
-<function>Date()</function> object, and to reduce the anonymity set by querying
-the <function>navigator</function> object for operating system, CPU, locale,
-and user agent information.
- <listitem><command>Inserting Plugins</command>
-Plugins are abysmal at obeying the proxy settings of the browser. Every plugin
-capable of performing network activity that the author has
-investigated is also capable of performing network activity independent of
-browser proxy settings - and often independent of its own proxy settings.
-Sites that have plugin content don't even have to be malicious to obtain a
-Non-Tor IP (it usually leaks by itself), though <ulink
-url="http://decloak.net">plenty of active
-exploits</ulink> are possible as well. In addition, plugins can be used to store unique identifiers that are more
-difficult to clear than standard cookies.
-cookies</ulink> fall into this category, but there are likely numerous other
+The browser contains multiple facilities for storing identifiers that the
+adversary creates for the purposes of tracking users. These identifiers are
+most obviously cookies, but also include HTTP auth, DOM storage, cached
+scripts and other elements with embedded identifiers, client certificates, and
+even TLS Session IDs.
- <listitem><command>Inserting CSS</command>
-CSS can also be used to correlate Tor and Non-Tor activity and reveal a user's
-Non-Tor IP address, via the usage of
-popups</ulink> - essentially CSS-based event handlers that fetch content via
-CSS's onmouseover attribute. If these popups are allowed to perform network
-activity in a different Tor state than they were loaded in, they can easily
-correlate Tor and Non-Tor activity and reveal a user's IP address. In
-url="http://ha.ckers.org/weird/CSS-history.cgi">CSS-only history disclosure
- <!-- XXX: Generalize to just identifiers -->
- <listitem><command>Read and insert cookies</command>
An adversary in a position to perform MITM content alteration can inject
document content elements to both read and inject cookies for arbitrary
-domains. In fact, many "SSL secured" websites are vulnerable to this sort of
+domains. In fact, even many "SSL secured" websites are vulnerable to this sort of
sidejacking</ulink>. In addition, the ad networks of course perform tracking
with cookies as well.
- <listitem><command>Create arbitrary cached content</command>
-Likewise, the browser cache can also be used to <ulink
-identifiers</ulink>. Since by default the cache has no same-origin policy,
-these identifiers can be read by any domain, making them an ideal target for
-ad network-class adversaries.
<listitem id="fingerprinting"><command>Fingerprint users based on browser
There is an absurd amount of information available to websites via attributes
of the browser. This information can be used to reduce anonymity set, or even
-fingerprint individual users</ulink>. </para>
+uniquely fingerprint individual users. Fingerprinting is an intimidating
+problem to attempt to tackle, especially without a metric to determine or at
+least intuitively understand and estimate which features will most contribute
+to linkability between visits.
-For illustration, let's perform a
-back-of-the-envelope calculation on the number of anonymity sets for just the
-resolution information available in the <ulink
-Browser window resolution information provides something like
-(1280-640)*(1024-480)=348160 different anonymity sets. Desktop resolution
-information contributes about another factor of 5 (for about 5 resolutions in
-typical use). In addition, the dimensions and position of the desktop taskbar
-are available, which can reveal hints on OS information. This boosts the count
-by a factor of 5 (for each of the major desktop taskbars - Windows, OSX, KDE
-and Gnome, and None). Subtracting the browser content window
-size from the browser outer window size provide yet more information.
-Firefox toolbar presence gives about a factor of 8 (3 toolbars on/off give
-2<superscript>3</superscript>=8). Interface effects such as title bar font size
-and window manager settings gives a factor of about 9 (say 3 common font sizes
-for the title bar and 3 common sizes for browser GUI element fonts).
-Multiply this all out, and you have (1280-640)*(1024-480)*5*5*8*9 ~=
-2<superscript>29</superscript>, or a 29 bit identifier based on resolution
-information alone. </para>
-done</ulink> by the EFF attempts to measure the actual entropy - the number of
-identifying bits of information encoded in browser properties. Their result
-data is definitely useful, and the metric is probably the appropriate one for
+The <ulink url="https://panopticlick.eff.org/about.php">Panopticlick study
+done</ulink> by the EFF uses the actual entropy - the number of identifying
+bits of information encoded in browser properties - as this metric. Their
+<ulink url="https://wiki.mozilla.org/Fingerprinting#Data">result data</ulink>
+is definitely useful, and the metric is probably the appropriate one for
determining how identifying a particular browser property is. However, some
quirks of their study means that they do not extract as much information as
they could from display information: they only use desktop resolution (which
Torbutton reports as the window resolution) and do not attempt to infer the
-size of toolbars.
+size of toolbars. In the other direction, they may be overcounting in some
+areas, as they did not compute joint entropy over multiple attributes that may
+exhibit a high degree of correlation. Also, new browser features are added
+regularly, so the data should not be taken as final.
-<!-- XXX: Also, new browser features are added regularly. -->
+Despite the uncertainty, all fingerprinting attacks leverage the following
+ <listitem><command>Observing Request Behavior</command>
+Properties of the user's request behavior comprise the bulk of low-hanging
+fingerprintig targets. These include: User agent, Accept-* headers, pipeline
+useage, and request ordering. Additionally, the use of custom filters such as
+AdBlock and other privacy filters can be used to fingerprint request patterns
+(as an extreme example).
+objects, just as window.screen and window.navigator to extract information
+via the <function>Date()</function> object, and to use timing information to
+<ulink url="http://w2spconf.com/2011/papers/jspriv.pdf">fingerprint the CPU
+and interpreter speed</ulink>.
+<!-- FIXME: resource-timing stuff? -->
+ <listitem><command>Inserting Plugins</command>
+The Panopticlick project found that the mere list of installed plugins (in
+navigator.plugins) was sufficient to provide a large degree of
+fingerprintability. Additionally, plugins are capable of extracing font lists,
+interface addresses, and other machine information that is beyond what the
+browser would normally provide to content. In addition, plugins can be used to
+store unique identifiers that are more difficult to clear than standard
+cookies. <ulink url="http://epic.org/privacy/cookies/flash.html">Flash-based
+cookies</ulink> fall into this category, but there are likely numerous other
+examples. Beyond fingerprinting, plugins are also abysmal at obeying the proxy
+settings of the browser.
+ <listitem><command>Inserting CSS</command>
+<ulink url="https://developer.mozilla.org/En/CSS/Media_queries">CSS media
+queries</ulink> can be inserted to gather information about the desktop size,
+widget size, display type, DPI, user agent type, and other information that
<listitem><command>Remotely or locally exploit browser and/or
@@ -659,8 +642,9 @@ SOCKS proxy. It sets <command>network.proxy.socks_remote_dns</command>,
- Plugins have the ability to make arbitrary OS system calls. This includes
+ <para>Plugins have the ability to make arbitrary OS system calls and <ulink
+url="http://decloak.net/">bypass proxy settings</ulink>. This includes
the ability to make UDP sockets and send arbitrary data independent of the
browser proxy settings.
@@ -678,6 +662,13 @@ url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src
for Flash and Gnash</ulink>.
+Finally, even if the user alters their browser settings to re-enable the Flash
+plugin, we have configured NoScript to provide click-to-play placeholders, so
+that only desired objects will be loaded, and only after user confirmation.
<listitem>External App Blocking
More information about the tor-commits