docs/known_issues.txt

   1 = known issues =
   2
   3 *  overview
   4 *  issues in Tahoe-LAFS v1.8.0c2, released 2010-08-10
   5   -  potential unauthorized access by JavaScript in unrelated files
   6   -  potential disclosure of file through embedded hyperlinks or JavaScript in that file
   7   -  command-line arguments are leaked to other local users
   8   -  capabilities may be leaked to web browser phishing filter / "safe browsing" servers ===
   9   -  known issues in the FTP and SFTP frontends ===
  10
  11 == overview ==
  12
  13 Below is a list of known issues in recent releases of Tahoe-LAFS, and how to
  14 manage them.  The current version of this file can be found at
  15
  16 http://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/known_issues.txt
  17
  18 If you've been using Tahoe-LAFS since v1.1 (released 2008-06-11) or if you're
  19 just curious about what sort of mistakes we've made in the past, then you might
  20 want to read the "historical known issues" document:
  21
  22 http://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/historical/historical_known_issues.txt
  23
  24 == issues in Tahoe-LAFS v1.7.0, released 2010-06-18 ==
  25
  26 === potential unauthorized access by JavaScript in unrelated files ===
  27
  28 If you view a file stored in Tahoe-LAFS through a web user interface,
  29 JavaScript embedded in that file might be able to access other files or
  30 directories stored in Tahoe-LAFS which you view through the same web
  31 user interface.  Such a script would be able to send the contents of
  32 those other files or directories to the author of the script, and if you
  33 have the ability to modify the contents of those files or directories,
  34 then that script could modify or delete those files or directories.
  35
  36 ==== how to manage it ====
  37
  38 For future versions of Tahoe-LAFS, we are considering ways to close off
  39 this leakage of authority while preserving ease of use -- the discussion
  40 of this issue is ticket #615.
  41
  42 For the present, either do not view files stored in Tahoe-LAFS through a
  43 web user interface, or turn off JavaScript in your web browser before
  44 doing so, or limit your viewing to files which you know don't contain
  45 malicious JavaScript.
  46
  47
  48 === potential disclosure of file through embedded hyperlinks or JavaScript in that file ===
  49
  50 If there is a file stored on a Tahoe-LAFS storage grid, and that file
  51 gets downloaded and displayed in a web browser, then JavaScript or
  52 hyperlinks within that file can leak the capability to that file to a
  53 third party, which means that third party gets access to the file.
  54
  55 If there is JavaScript in the file, then it could deliberately leak
  56 the capability to the file out to some remote listener.
  57
  58 If there are hyperlinks in the file, and they get followed, then
  59 whichever server they point to receives the capability to the
  60 file. Note that IMG tags are typically followed automatically by web
  61 browsers, so being careful which hyperlinks you click on is not
  62 sufficient to prevent this from happening.
  63
  64 ==== how to manage it ====
  65
  66 For future versions of Tahoe-LAFS, we are considering ways to close off
  67 this leakage of authority while preserving ease of use -- the discussion
  68 of this issue is ticket #127.
  69
  70 For the present, a good work-around is that if you want to store and
  71 view a file on Tahoe-LAFS and you want that file to remain private, then
  72 remove from that file any hyperlinks pointing to other people's servers
  73 and remove any JavaScript unless you are sure that the JavaScript is not
  74 written to maliciously leak access.
  75
  76
  77 === command-line arguments are leaked to other local users ===
  78
  79 Remember that command-line arguments are visible to other users (through
  80 the 'ps' command, or the windows Process Explorer tool), so if you are
  81 using a Tahoe-LAFS node on a shared host, other users on that host will
  82 be able to see (and copy) any caps that you pass as command-line
  83 arguments.  This includes directory caps that you set up with the "tahoe
  84 add-alias" command.
  85
  86 ==== how to manage it ====
  87
  88 As of Tahoe-LAFS v1.3.0 there is a "tahoe create-alias" command that does
  89 the following technique for you.
  90
  91 Bypass add-alias and edit the NODEDIR/private/aliases file directly, by
  92 adding a line like this:
  93
  94 fun: URI:DIR2:ovjy4yhylqlfoqg2vcze36dhde:4d4f47qko2xm5g7osgo2yyidi5m4muyo2vjjy53q4vjju2u55mfa
  95
  96 By entering the dircap through the editor, the command-line arguments
  97 are bypassed, and other users will not be able to see them. Once you've
  98 added the alias, if you use that alias instead of a cap itself on the
  99 command-line, then no secrets are passed through the command line.  Then
 100 other processes on the system can still see your filenames and other
 101 arguments you type there, but not the caps that Tahoe-LAFS uses to permit
 102 access to your files and directories.
 103
 104
 105 === capabilities may be leaked to web browser phishing filter / "safe browsing" servers ===
 106
 107 Firefox, Internet Explorer, and Chrome include a "phishing filter" or
 108 "safe browing" component, which is turned on by default, and which sends
 109 any URLs that it deems suspicious to a central server.
 110
 111 Microsoft gives a brief description of their filter's operation at
 112 <http://blogs.msdn.com/ie/archive/2005/09/09/463204.aspx>. Firefox
 113 and Chrome both use Google's "safe browsing API" which is documented
 114 at <http://code.google.com/apis/safebrowsing/> and
 115 <http://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec>.
 116
 117 This of course has implications for the privacy of general web browsing
 118 (especially in the cases of Firefox and Chrome, which send your main
 119 personally identifying Google cookie along with these requests without
 120 your explicit consent, as described for Firefox in
 121 <https://bugzilla.mozilla.org/show_bug.cgi?id=368255>).
 122
 123 The reason for documenting this issue here, though, is that when using the
 124 Tahoe-LAFS web user interface, it could also affect confidentiality and integrity
 125 by leaking capabilities to the filter server.
 126
 127 Since IE's filter sends URLs by SSL/TLS, the exposure of caps is limited to
 128 the filter server operators (or anyone able to hack the filter server) rather
 129 than to network eavesdroppers. The "safe browsing API" protocol used by
 130 Firefox and Chrome, on the other hand, is *not* encrypted, although the
 131 URL components are normally hashed.
 132
 133 Opera also has a similar facility that is disabled by default. A previous
 134 version of this file stated that Firefox had abandoned their phishing
 135 filter; this was incorrect.
 136
 137 ==== how to manage it ====
 138
 139 If you use any phishing filter or "safe browsing" feature, consider either
 140 disabling it, or not using the WUI via that browser. Phishing filters have
 141 very limited effectiveness (see
 142 <http://lorrie.cranor.org/pubs/ndss-phish-tools-final.pdf>), and phishing
 143 or malware attackers have learnt how to bypass them.
 144
 145 To disable the filter in IE7 or IE8:
 146  - Click Internet Options from the Tools menu.
 147  - Click the Advanced tab.
 148  - If an "Enable SmartScreen Filter" option is present, uncheck it.
 149    If a "Use Phishing Filter" or "Phishing Filter" option is present,
 150    set it to Disable.
 151  - Confirm (click OK or Yes) out of all dialogs.
 152
 153 If you have a version of IE that splits the settings between security
 154 zones, do this for all zones.
 155
 156 To disable the filter in Firefox:
 157  - Click Options from the Tools menu.
 158  - Click the Security tab.
 159  - Uncheck both the "Block reported attack sites" and "Block reported
 160    web forgeries" options.
 161  - Click OK.
 162
 163 To disable the filter in Chrome:
 164  - Click Options from the Tools menu.
 165  - Click the "Under the Hood" tab and find the "Privacy" section.
 166  - Uncheck the "Enable phishing and malware protection" option.
 167  - Click Close.
 168
 169
 170 === known issues in the FTP and SFTP frontends ===
 171
 172 These are documented in docs/frontends/FTP-and-SFTP.txt and at
 173 <http://tahoe-lafs.org/trac/tahoe-lafs/wiki/SftpFrontend>.