[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
commit bdfc51217eca3e1e5e87e730c467d47fa1e2d002
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
--- a/docs/design/design.xml
+++ b/docs/design/design.xml
@@ -173,136 +173,119 @@ performed by malicious agents on the Tor network and at national firewalls.
</para>
<orderedlist>
- <listitem><command>Inserting Javascript</command>
+ <listitem><command>Read and insert identifiers</command>
<para>
-If not properly disabled, Javascript event handlers and timers
-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
-a user's non-Tor IP address. Javascript
-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
-url="http://www.mikeonads.com/2008/07/13/using-your-browser-url-history-estimate-gender/">profile
-users based on gender and other classifications</ulink>. Finally,
-Javascript can be used to query the user's timezone via the
-<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.
- </para>
- </listitem>
- <listitem><command>Inserting Plugins</command>
- <para>
-
-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
-user's
-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.
-<ulink url="http://epic.org/privacy/cookies/flash.html">Flash-based
-cookies</ulink> fall into this category, but there are likely numerous other
-examples.
+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.
</para>
- </listitem>
- <listitem><command>Inserting CSS</command>
- <para>
-
-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
-<ulink url="http://www.tjkdesign.com/articles/css%20pop%20ups/">CSS
-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
-addition, CSS can also be used without Javascript to perform <ulink
-url="http://ha.ckers.org/weird/CSS-history.cgi">CSS-only history disclosure
-attacks</ulink>.
- </para>
- </listitem>
- <!-- XXX: Generalize to just identifiers -->
- <listitem><command>Read and insert cookies</command>
<para>
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
<ulink url="http://seclists.org/bugtraq/2007/Aug/0070.html">active
sidejacking</ulink>. In addition, the ad networks of course perform tracking
with cookies as well.
</para>
</listitem>
- <listitem><command>Create arbitrary cached content</command>
- <para>
-
-Likewise, the browser cache can also be used to <ulink
-url="http://crypto.stanford.edu/sameorigin/safecachetest.html">store unique
-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.
-
- </para>
- </listitem>
-
<listitem id="fingerprinting"><command>Fingerprint users based on browser
attributes</command>
<para>
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
-<ulink url="http://mandark.fr/0x000000/articles/Total_Recall_On_Firefox..html">uniquely
-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.
+
+</para>
-<!--
-<para>
-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
-url="http://developer.mozilla.org/en/docs/DOM:window">window</ulink> and
-<ulink
-url="http://developer.mozilla.org/en/docs/DOM:window.screen">window.screen</ulink>
-objects.
-
-
-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>
--->
<para>
-The <ulink
-url="https://wiki.mozilla.org/Fingerprinting#Data">Panopticlick study
-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. -->
+ </para>
+ <para>
-</para>
+Despite the uncertainty, all fingerprinting attacks leverage the following
+attack vectors:
+
+ </para>
+ <orderedlist>
+ <listitem><command>Observing Request Behavior</command>
+ <para>
+
+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).
+
+ </para>
+ </listitem>
+
+ <listitem><command>Inserting Javascript</command>
+ <para>
+
+Javascript can reveal a lot of fingerprinting information. It provides DOM
+objects, just as window.screen and window.navigator to extract information
+about the useragent. Also, Javascript can be used to query the user's timezone
+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? -->
+
+ </para>
+ </listitem>
+
+ <listitem><command>Inserting Plugins</command>
+ <para>
+
+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.
+
+
+ </para>
+ </listitem>
+ <listitem><command>Inserting CSS</command>
+ <para>
+
+<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
+was formerly available only to Javascript.
+
+ </para>
+ </listitem>
+ </orderedlist>
</listitem>
<listitem><command>Remotely or locally exploit browser and/or
OS</command>
@@ -659,8 +642,9 @@ SOCKS proxy. It sets <command>network.proxy.socks_remote_dns</command>,
</listitem>
<listitem>Disabling plugins
- <para>
- 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.
</para>
@@ -678,6 +662,13 @@ url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src
for Flash and Gnash</ulink>.
</para>
+ <para>
+
+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.
+
+ </para>
</listitem>
<listitem>External App Blocking
<para>
More information about the tor-commits
mailing list