docs/known_issues.rst

   1 ============
   2 Known Issues
   3 ============
   4
   5 Below is a list of known issues in recent releases of Tahoe-LAFS, and how to
   6 manage them.  The current version of this file can be found at
   7 http://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/known_issues.rst .
   8
   9 If you've been using Tahoe-LAFS since v1.1 (released 2008-06-11) or if you're
  10 just curious about what sort of mistakes we've made in the past, then you might
  11 want to read `the "historical known issues" document`_.
  12
  13 .. _the "historical known issues" document: historical/historical_known_issues.txt
  14
  15
  16 Issues in Tahoe-LAFS v1.8.2, released 2011-01-30
  17
  18   *  `Unauthorized deletion of an immutable file by its storage index`_
  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 Unauthorized deletion of an immutable file by its storage index
  29 ---------------------------------------------------------------
  30
  31 Due to a flaw in the Tahoe-LAFS storage server software in v1.3.0 through
  32 v1.8.2, a person who knows the "storage index" that identifies an immutable
  33 file can cause the server to delete its shares of that file.
  34
  35 If an attacker can cause enough shares to be deleted from enough storage
  36 servers, this deletes the file.
  37
  38 This vulnerability does not enable anyone to read file contents without
  39 authorization (confidentiality), nor to change the contents of a file
  40 (integrity).
  41
  42 A person could learn the storage index of a file in several ways:
  43
  44 1. By being granted the authority to read the immutable file—i.e. by being
  45    granted a read capability to the file. They can determine the file's
  46    storage index from its read capability.
  47
  48 2. By being granted a verify capability to the file. They can determine the
  49    file's storage index from its verify capability. This case probably
  50    doesn't happen often because users typically don't share verify caps.
  51
  52 3. By operating a storage server, and receiving a request from a client that
  53    has a read cap or a verify cap. If the client attempts to upload,
  54    download, or verify the file with their storage server, even if it doesn't
  55    actually have the file, then they can learn the storage index of the file.
  56
  57 4. By gaining read access to an existing storage server's local filesystem,
  58    and inspecting the directory structure that it stores its shares in. They
  59    can thus learn the storage indexes of all files that the server is holding
  60    at least one share of. Normally only the operator of an existing storage
  61    server would be able to inspect its local filesystem, so this requires
  62    either being such an operator of an existing storage server, or somehow
  63    gaining the ability to inspect the local filesystem of an existing storage
  64    server.
  65
  66 *how to manage it*
  67
  68 Tahoe-LAFS version v1.8.3 or newer (except v1.9a1) no longer has this flaw;
  69 if you upgrade a storage server to a fixed release then that server is no
  70 longer vulnerable to this problem.
  71
  72 Note that the issue is local to each storage server independently of other
  73 storage servers—when you upgrade a storage server then that particular
  74 storage server can no longer be tricked into deleting its shares of the
  75 target file.
  76
  77 If you can't immediately upgrade your storage server to a version of
  78 Tahoe-LAFS that eliminates this vulnerability, then you could temporarily
  79 shut down your storage server. This would of course negatively impact
  80 availability—clients would not be able to upload or download shares to that
  81 particular storage server while it was shut down—but it would protect the
  82 shares already stored on that server from being deleted as long as the server
  83 is shut down.
  84
  85 If the servers that store shares of your file are running a version of
  86 Tahoe-LAFS with this vulnerability, then you should think about whether
  87 someone can learn the storage indexes of your files by one of the methods
  88 described above. A person can not exploit this vulnerability unless they have
  89 received a read cap or verify cap, or they control a storage server that has
  90 been queried about this file by a client that has a read cap or a verify cap.
  91
  92 Tahoe-LAFS does not currently have a mechanism to limit which storage servers
  93 can connect to your grid, but it does have a way to see which storage servers
  94 have been connected to the grid. The Introducer's front page in the Web User
  95 Interface has a list of all storage servers that the Introducer has ever seen
  96 and the first time and the most recent time that it saw them. Each Tahoe-LAFS
  97 gateway maintains a similar list on its front page in its Web User Interface,
  98 showing all of the storage servers that it learned about from the Introducer,
  99 when it first connected to that storage server, and when it most recently
 100 connected to that storage server. These lists are stored in memory and are
 101 reset to empty when the process is restarted.
 102
 103 See ticket `#1528`_ for technical details.
 104
 105 .. _#1528: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1528
 106
 107
 108 ----
 109
 110 Potential unauthorized access by JavaScript in unrelated files
 111 --------------------------------------------------------------
 112
 113 If you view a file stored in Tahoe-LAFS through a web user interface,
 114 JavaScript embedded in that file might be able to access other files or
 115 directories stored in Tahoe-LAFS which you view through the same web
 116 user interface.  Such a script would be able to send the contents of
 117 those other files or directories to the author of the script, and if you
 118 have the ability to modify the contents of those files or directories,
 119 then that script could modify or delete those files or directories.
 120
 121 *how to manage it*
 122
 123 For future versions of Tahoe-LAFS, we are considering ways to close off
 124 this leakage of authority while preserving ease of use -- the discussion
 125 of this issue is ticket `#615`_.
 126
 127 For the present, either do not view files stored in Tahoe-LAFS through a
 128 web user interface, or turn off JavaScript in your web browser before
 129 doing so, or limit your viewing to files which you know don't contain
 130 malicious JavaScript.
 131
 132 .. _#615: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/615
 133
 134
 135 ----
 136
 137 Potential disclosure of file through embedded hyperlinks or JavaScript in that file
 138 -----------------------------------------------------------------------------------
 139
 140 If there is a file stored on a Tahoe-LAFS storage grid, and that file
 141 gets downloaded and displayed in a web browser, then JavaScript or
 142 hyperlinks within that file can leak the capability to that file to a
 143 third party, which means that third party gets access to the file.
 144
 145 If there is JavaScript in the file, then it could deliberately leak
 146 the capability to the file out to some remote listener.
 147
 148 If there are hyperlinks in the file, and they get followed, then
 149 whichever server they point to receives the capability to the
 150 file. Note that IMG tags are typically followed automatically by web
 151 browsers, so being careful which hyperlinks you click on is not
 152 sufficient to prevent this from happening.
 153
 154 *how to manage it*
 155
 156 For future versions of Tahoe-LAFS, we are considering ways to close off
 157 this leakage of authority while preserving ease of use -- the discussion
 158 of this issue is ticket `#127`_.
 159
 160 For the present, a good work-around is that if you want to store and
 161 view a file on Tahoe-LAFS and you want that file to remain private, then
 162 remove from that file any hyperlinks pointing to other people's servers
 163 and remove any JavaScript unless you are sure that the JavaScript is not
 164 written to maliciously leak access.
 165
 166 .. _#127: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/127
 167
 168
 169 ----
 170
 171 Command-line arguments are leaked to other local users
 172 ------------------------------------------------------
 173
 174 Remember that command-line arguments are visible to other users (through
 175 the 'ps' command, or the windows Process Explorer tool), so if you are
 176 using a Tahoe-LAFS node on a shared host, other users on that host will
 177 be able to see (and copy) any caps that you pass as command-line
 178 arguments.  This includes directory caps that you set up with the "tahoe
 179 add-alias" command.
 180
 181 *how to manage it*
 182
 183 As of Tahoe-LAFS v1.3.0 there is a "tahoe create-alias" command that does
 184 the following technique for you.
 185
 186 Bypass add-alias and edit the NODEDIR/private/aliases file directly, by
 187 adding a line like this:
 188
 189   fun: URI:DIR2:ovjy4yhylqlfoqg2vcze36dhde:4d4f47qko2xm5g7osgo2yyidi5m4muyo2vjjy53q4vjju2u55mfa
 190
 191 By entering the dircap through the editor, the command-line arguments
 192 are bypassed, and other users will not be able to see them. Once you've
 193 added the alias, if you use that alias instead of a cap itself on the
 194 command-line, then no secrets are passed through the command line.  Then
 195 other processes on the system can still see your filenames and other
 196 arguments you type there, but not the caps that Tahoe-LAFS uses to permit
 197 access to your files and directories.
 198
 199
 200 ----
 201
 202 Capabilities may be leaked to web browser phishing filter / "safe browsing" servers
 203 -----------------------------------------------------------------------------------
 204
 205 Firefox, Internet Explorer, and Chrome include a "phishing filter" or
 206 "safe browing" component, which is turned on by default, and which sends
 207 any URLs that it deems suspicious to a central server.
 208
 209 Microsoft gives `a brief description of their filter's operation`_. Firefox
 210 and Chrome both use Google's `"safe browsing API"`_ (`specification`_).
 211
 212 This of course has implications for the privacy of general web browsing
 213 (especially in the cases of Firefox and Chrome, which send your main
 214 personally identifying Google cookie along with these requests without your
 215 explicit consent, as described in `Firefox bugzilla ticket #368255`_.
 216
 217 The reason for documenting this issue here, though, is that when using the
 218 Tahoe-LAFS web user interface, it could also affect confidentiality and integrity
 219 by leaking capabilities to the filter server.
 220
 221 Since IE's filter sends URLs by SSL/TLS, the exposure of caps is limited to
 222 the filter server operators (or anyone able to hack the filter server) rather
 223 than to network eavesdroppers. The "safe browsing API" protocol used by
 224 Firefox and Chrome, on the other hand, is *not* encrypted, although the
 225 URL components are normally hashed.
 226
 227 Opera also has a similar facility that is disabled by default. A previous
 228 version of this file stated that Firefox had abandoned their phishing
 229 filter; this was incorrect.
 230
 231 .. _a brief description of their filter's operation: http://blogs.msdn.com/ie/archive/2005/09/09/463204.aspx
 232 .. _"safe browsing API": http://code.google.com/apis/safebrowsing/
 233 .. _specification: http://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec
 234 .. _Firefox bugzilla ticket #368255: https://bugzilla.mozilla.org/show_bug.cgi?id=368255
 235
 236
 237 *how to manage it*
 238
 239 If you use any phishing filter or "safe browsing" feature, consider either
 240 disabling it, or not using the WUI via that browser. Phishing filters have
 241 `very limited effectiveness`_ , and phishing or malware attackers have learnt
 242 how to bypass them.
 243
 244 .. _very limited effectiveness: http://lorrie.cranor.org/pubs/ndss-phish-tools-final.pdf
 245
 246 To disable the filter in IE7 or IE8:
 247 ++++++++++++++++++++++++++++++++++++
 248
 249 - Click Internet Options from the Tools menu.
 250
 251 - Click the Advanced tab.
 252
 253 - If an "Enable SmartScreen Filter" option is present, uncheck it.
 254   If a "Use Phishing Filter" or "Phishing Filter" option is present,
 255   set it to Disable.
 256
 257 - Confirm (click OK or Yes) out of all dialogs.
 258
 259 If you have a version of IE that splits the settings between security
 260 zones, do this for all zones.
 261
 262 To disable the filter in Firefox:
 263 +++++++++++++++++++++++++++++++++
 264
 265 - Click Options from the Tools menu.
 266
 267 - Click the Security tab.
 268
 269 - Uncheck both the "Block reported attack sites" and "Block reported
 270   web forgeries" options.
 271
 272 - Click OK.
 273
 274 To disable the filter in Chrome:
 275 ++++++++++++++++++++++++++++++++
 276
 277 - Click Options from the Tools menu.
 278
 279 - Click the "Under the Hood" tab and find the "Privacy" section.
 280
 281 - Uncheck the "Enable phishing and malware protection" option.
 282
 283 - Click Close.
 284
 285
 286 ----
 287
 288 Known issues in the FTP and SFTP frontends
 289 ------------------------------------------
 290
 291 These are documented in `docs/frontends/FTP-and-SFTP.rst`_ and on `the SftpFrontend page`_ on the wiki.
 292
 293 .. _docs/frontends/FTP-and-SFTP.rst: frontends/FTP-and-SFTP.rst
 294 .. _the SftpFrontend page: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/SftpFrontend
 295
 296
 297 ----
 298
 299 Traffic analysis based on sizes of files/directories, storage indices, and timing
 300 ---------------------------------------------------------------------------------
 301
 302 Files and directories stored by Tahoe-LAFS are encrypted, but the ciphertext
 303 reveals the exact size of the original file or directory representation.
 304 This information is available to passive eavesdroppers and to server operators.
 305
 306 For example, a large data set with known file sizes could probably be
 307 identified with a high degree of confidence.
 308
 309 Uploads and downloads of the same file or directory can be linked by server
 310 operators, even without making assumptions based on file size. Anyone who
 311 knows the introducer furl for a grid may be able to act as a server operator.
 312 This implies that if such an attacker knows which file/directory is being
 313 accessed in a particular request (by some other form of surveillance, say),
 314 then they can identify later or earlier accesses of the same file/directory.
 315
 316 Observing requests during a directory traversal (such as a deep-check
 317 operation) could reveal information about the directory structure, i.e.
 318 which files and subdirectories are linked from a given directory.
 319
 320 Attackers can combine the above information with inferences based on timing
 321 correlations. For instance, two files that are accessed close together in
 322 time are likely to be related even if they are not linked in the directory
 323 structure. Also, users that access the same files may be related to each other.