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