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