docs/known_issues.rst

   1
   2 ============
   3 Known Issues
   4 ============
   5
   6 Below is a list of known issues in recent releases of Tahoe-LAFS, and how to
   7 manage them.  The current version of this file can be found at
   8 https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/known_issues.rst .
   9
  10 If you've been using Tahoe-LAFS since v1.1 (released 2008-06-11) or if you're
  11 just curious about what sort of mistakes we've made in the past, then you might
  12 want to read `the "historical known issues" document`_.
  13
  14 .. _the "historical known issues" document: historical/historical_known_issues.txt
  15
  16
  17 Known Issues in Tahoe-LAFS v1.9.0, released 31-Oct-2011
  18
  19   *  `Potential unauthorized access by JavaScript in unrelated files`_
  20   *  `Potential disclosure of file through embedded hyperlinks or JavaScript in that file`_
  21   *  `Command-line arguments are leaked to other local users`_
  22   *  `Capabilities may be leaked to web browser phishing filter / "safe browsing" servers`_
  23   *  `Known issues in the FTP and SFTP frontends`_
  24   *  `Traffic analysis based on sizes of files/directories, storage indices, and timing`_
  25
  26 ----
  27
  28 Potential unauthorized access by JavaScript in unrelated files
  29 --------------------------------------------------------------
  30
  31 If you view a file stored in Tahoe-LAFS through a web user interface,
  32 JavaScript embedded in that file might be able to access other files or
  33 directories stored in Tahoe-LAFS which you view through the same web
  34 user interface.  Such a script would be able to send the contents of
  35 those other files or directories to the author of the script, and if you
  36 have the ability to modify the contents of those files or directories,
  37 then that script could modify or delete those files or directories.
  38
  39 *how to manage it*
  40
  41 For future versions of Tahoe-LAFS, we are considering ways to close off
  42 this leakage of authority while preserving ease of use -- the discussion
  43 of this issue is ticket `#615`_.
  44
  45 For the present, either do not view files stored in Tahoe-LAFS through a
  46 web user interface, or turn off JavaScript in your web browser before
  47 doing so, or limit your viewing to files which you know don't contain
  48 malicious JavaScript.
  49
  50 .. _#615: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/615
  51
  52
  53 ----
  54
  55 Potential disclosure of file through embedded hyperlinks or JavaScript in that file
  56 -----------------------------------------------------------------------------------
  57
  58 If there is a file stored on a Tahoe-LAFS storage grid, and that file
  59 gets downloaded and displayed in a web browser, then JavaScript or
  60 hyperlinks within that file can leak the capability to that file to a
  61 third party, which means that third party gets access to the file.
  62
  63 If there is JavaScript in the file, then it could deliberately leak
  64 the capability to the file out to some remote listener.
  65
  66 If there are hyperlinks in the file, and they get followed, then
  67 whichever server they point to receives the capability to the
  68 file. Note that IMG tags are typically followed automatically by web
  69 browsers, so being careful which hyperlinks you click on is not
  70 sufficient to prevent this from happening.
  71
  72 *how to manage it*
  73
  74 For future versions of Tahoe-LAFS, we are considering ways to close off
  75 this leakage of authority while preserving ease of use -- the discussion
  76 of this issue is ticket `#127`_.
  77
  78 For the present, a good work-around is that if you want to store and
  79 view a file on Tahoe-LAFS and you want that file to remain private, then
  80 remove from that file any hyperlinks pointing to other people's servers
  81 and remove any JavaScript unless you are sure that the JavaScript is not
  82 written to maliciously leak access.
  83
  84 .. _#127: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/127
  85
  86
  87 ----
  88
  89 Command-line arguments are leaked to other local users
  90 ------------------------------------------------------
  91
  92 Remember that command-line arguments are visible to other users (through
  93 the 'ps' command, or the windows Process Explorer tool), so if you are
  94 using a Tahoe-LAFS node on a shared host, other users on that host will
  95 be able to see (and copy) any caps that you pass as command-line
  96 arguments.  This includes directory caps that you set up with the "tahoe
  97 add-alias" command.
  98
  99 *how to manage it*
 100
 101 As of Tahoe-LAFS v1.3.0 there is a "tahoe create-alias" command that does
 102 the following technique for you.
 103
 104 Bypass add-alias and edit the NODEDIR/private/aliases file directly, by
 105 adding a line like this:
 106
 107   fun: URI:DIR2:ovjy4yhylqlfoqg2vcze36dhde:4d4f47qko2xm5g7osgo2yyidi5m4muyo2vjjy53q4vjju2u55mfa
 108
 109 By entering the dircap through the editor, the command-line arguments
 110 are bypassed, and other users will not be able to see them. Once you've
 111 added the alias, if you use that alias instead of a cap itself on the
 112 command-line, then no secrets are passed through the command line.  Then
 113 other processes on the system can still see your filenames and other
 114 arguments you type there, but not the caps that Tahoe-LAFS uses to permit
 115 access to your files and directories.
 116
 117
 118 ----
 119
 120 Capabilities may be leaked to web browser phishing filter / "safe browsing" servers
 121 -----------------------------------------------------------------------------------
 122
 123 Firefox, Internet Explorer, and Chrome include a "phishing filter" or
 124 "safe browing" component, which is turned on by default, and which sends
 125 any URLs that it deems suspicious to a central server.
 126
 127 Microsoft gives `a brief description of their filter's operation`_. Firefox
 128 and Chrome both use Google's `"safe browsing API"`_ (`specification`_).
 129
 130 This of course has implications for the privacy of general web browsing
 131 (especially in the cases of Firefox and Chrome, which send your main
 132 personally identifying Google cookie along with these requests without your
 133 explicit consent, as described in `Firefox bugzilla ticket #368255`_.
 134
 135 The reason for documenting this issue here, though, is that when using the
 136 Tahoe-LAFS web user interface, it could also affect confidentiality and integrity
 137 by leaking capabilities to the filter server.
 138
 139 Since IE's filter sends URLs by SSL/TLS, the exposure of caps is limited to
 140 the filter server operators (or anyone able to hack the filter server) rather
 141 than to network eavesdroppers. The "safe browsing API" protocol used by
 142 Firefox and Chrome, on the other hand, is *not* encrypted, although the
 143 URL components are normally hashed.
 144
 145 Opera also has a similar facility that is disabled by default. A previous
 146 version of this file stated that Firefox had abandoned their phishing
 147 filter; this was incorrect.
 148
 149 .. _a brief description of their filter's operation: http://blogs.msdn.com/ie/archive/2005/09/09/463204.aspx
 150 .. _"safe browsing API": http://code.google.com/apis/safebrowsing/
 151 .. _specification: http://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec
 152 .. _Firefox bugzilla ticket #368255: https://bugzilla.mozilla.org/show_bug.cgi?id=368255
 153
 154
 155 *how to manage it*
 156
 157 If you use any phishing filter or "safe browsing" feature, consider either
 158 disabling it, or not using the WUI via that browser. Phishing filters have
 159 `very limited effectiveness`_ , and phishing or malware attackers have learnt
 160 how to bypass them.
 161
 162 .. _very limited effectiveness: http://lorrie.cranor.org/pubs/ndss-phish-tools-final.pdf
 163
 164 To disable the filter in IE7 or IE8:
 165 ++++++++++++++++++++++++++++++++++++
 166
 167 - Click Internet Options from the Tools menu.
 168
 169 - Click the Advanced tab.
 170
 171 - If an "Enable SmartScreen Filter" option is present, uncheck it.
 172   If a "Use Phishing Filter" or "Phishing Filter" option is present,
 173   set it to Disable.
 174
 175 - Confirm (click OK or Yes) out of all dialogs.
 176
 177 If you have a version of IE that splits the settings between security
 178 zones, do this for all zones.
 179
 180 To disable the filter in Firefox:
 181 +++++++++++++++++++++++++++++++++
 182
 183 - Click Options from the Tools menu.
 184
 185 - Click the Security tab.
 186
 187 - Uncheck both the "Block reported attack sites" and "Block reported
 188   web forgeries" options.
 189
 190 - Click OK.
 191
 192 To disable the filter in Chrome:
 193 ++++++++++++++++++++++++++++++++
 194
 195 - Click Options from the Tools menu.
 196
 197 - Click the "Under the Hood" tab and find the "Privacy" section.
 198
 199 - Uncheck the "Enable phishing and malware protection" option.
 200
 201 - Click Close.
 202
 203
 204 ----
 205
 206 Known issues in the FTP and SFTP frontends
 207 ------------------------------------------
 208
 209 These are documented in `docs/frontends/FTP-and-SFTP.rst`_ and on `the SftpFrontend page`_ on the wiki.
 210
 211 .. _docs/frontends/FTP-and-SFTP.rst: frontends/FTP-and-SFTP.rst
 212 .. _the SftpFrontend page: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/SftpFrontend
 213
 214
 215 ----
 216
 217 Traffic analysis based on sizes of files/directories, storage indices, and timing
 218 ---------------------------------------------------------------------------------
 219
 220 Files and directories stored by Tahoe-LAFS are encrypted, but the ciphertext
 221 reveals the exact size of the original file or directory representation.
 222 This information is available to passive eavesdroppers and to server operators.
 223
 224 For example, a large data set with known file sizes could probably be
 225 identified with a high degree of confidence.
 226
 227 Uploads and downloads of the same file or directory can be linked by server
 228 operators, even without making assumptions based on file size. Anyone who
 229 knows the introducer furl for a grid may be able to act as a server operator.
 230 This implies that if such an attacker knows which file/directory is being
 231 accessed in a particular request (by some other form of surveillance, say),
 232 then they can identify later or earlier accesses of the same file/directory.
 233
 234 Observing requests during a directory traversal (such as a deep-check
 235 operation) could reveal information about the directory structure, i.e.
 236 which files and subdirectories are linked from a given directory.
 237
 238 Attackers can combine the above information with inferences based on timing
 239 correlations. For instance, two files that are accessed close together in
 240 time are likely to be related even if they are not linked in the directory
 241 structure. Also, users that access the same files may be related to each other.