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 .
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`_.
14 .. _the "historical known issues" document: historical/historical_known_issues.txt
17 Known Issues in Tahoe-LAFS v1.9.0, released 31-Oct-2011
18 =======================================================
20 * `Integrity Failure during Mutable Downloads`_
21 * `Potential unauthorized access by JavaScript in unrelated files`_
22 * `Potential disclosure of file through embedded hyperlinks or JavaScript in that file`_
23 * `Command-line arguments are leaked to other local users`_
24 * `Capabilities may be leaked to web browser phishing filter / "safe browsing" servers`_
25 * `Known issues in the FTP and SFTP frontends`_
26 * `Traffic analysis based on sizes of files/directories, storage indices, and timing`_
30 Integrity Failure during Mutable Downloads
31 --------------------------------------------------------------
33 Under certain circumstances, the integrity-verification code of the mutable
34 downloader could be bypassed. Clients who receive carefully crafted shares
35 (from attackers) will emit incorrect file contents, and the usual
36 share-corruption errors would not be raised. This only affects mutable files
37 (not immutable), and only affects downloads that use doctored shares. It is
38 not persistent: the threat is resolved once you upgrade your client to a
39 version without the bug. However, read-modify-write operations (such as
40 directory manipulations) performed by vulnerable clients could cause the
41 attacker's modifications to be written back out to the mutable file, making
42 the corruption permanent.
44 The attacker's ability to manipulate the file contents is limited. They can
45 modify FEC-encoded ciphertext in all but one share. This gives them the
46 ability to blindly flip bits in roughly 2/3rds of the file (for the default
47 k=3 encoding parameter). Confidentiality remains intact, unless the attacker
48 can deduce the file's contents by observing your reactions to corrupted
51 This bug was introduced in 1.9.0, as part of the MDMF-capable downloader, and
52 affects both SDMF and MDMF files. It was not present in 1.8.3.
56 There are three options:
58 * Upgrade to 1.9.1, which fixes the bug
59 * Downgrade to 1.8.3, which does not contain the bug
60 * If using 1.9.0, do not trust the contents of mutable files (whether SDMF or
61 MDMF) that the 1.9.0 client emits, and do not modify directories (which
62 could write the corrupted data back into place, making the damage
66 .. _#1654: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1654
70 Potential unauthorized access by JavaScript in unrelated files
71 --------------------------------------------------------------
73 If you view a file stored in Tahoe-LAFS through a web user interface,
74 JavaScript embedded in that file might be able to access other files or
75 directories stored in Tahoe-LAFS which you view through the same web
76 user interface. Such a script would be able to send the contents of
77 those other files or directories to the author of the script, and if you
78 have the ability to modify the contents of those files or directories,
79 then that script could modify or delete those files or directories.
83 For future versions of Tahoe-LAFS, we are considering ways to close off
84 this leakage of authority while preserving ease of use -- the discussion
85 of this issue is ticket `#615`_.
87 For the present, either do not view files stored in Tahoe-LAFS through a
88 web user interface, or turn off JavaScript in your web browser before
89 doing so, or limit your viewing to files which you know don't contain
92 .. _#615: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/615
97 Potential disclosure of file through embedded hyperlinks or JavaScript in that file
98 -----------------------------------------------------------------------------------
100 If there is a file stored on a Tahoe-LAFS storage grid, and that file
101 gets downloaded and displayed in a web browser, then JavaScript or
102 hyperlinks within that file can leak the capability to that file to a
103 third party, which means that third party gets access to the file.
105 If there is JavaScript in the file, then it could deliberately leak
106 the capability to the file out to some remote listener.
108 If there are hyperlinks in the file, and they get followed, then
109 whichever server they point to receives the capability to the
110 file. Note that IMG tags are typically followed automatically by web
111 browsers, so being careful which hyperlinks you click on is not
112 sufficient to prevent this from happening.
116 For future versions of Tahoe-LAFS, we are considering ways to close off
117 this leakage of authority while preserving ease of use -- the discussion
118 of this issue is ticket `#127`_.
120 For the present, a good work-around is that if you want to store and
121 view a file on Tahoe-LAFS and you want that file to remain private, then
122 remove from that file any hyperlinks pointing to other people's servers
123 and remove any JavaScript unless you are sure that the JavaScript is not
124 written to maliciously leak access.
126 .. _#127: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/127
131 Command-line arguments are leaked to other local users
132 ------------------------------------------------------
134 Remember that command-line arguments are visible to other users (through
135 the 'ps' command, or the windows Process Explorer tool), so if you are
136 using a Tahoe-LAFS node on a shared host, other users on that host will
137 be able to see (and copy) any caps that you pass as command-line
138 arguments. This includes directory caps that you set up with the "tahoe
143 As of Tahoe-LAFS v1.3.0 there is a "tahoe create-alias" command that does
144 the following technique for you.
146 Bypass add-alias and edit the NODEDIR/private/aliases file directly, by
147 adding a line like this:
149 fun: URI:DIR2:ovjy4yhylqlfoqg2vcze36dhde:4d4f47qko2xm5g7osgo2yyidi5m4muyo2vjjy53q4vjju2u55mfa
151 By entering the dircap through the editor, the command-line arguments
152 are bypassed, and other users will not be able to see them. Once you've
153 added the alias, if you use that alias instead of a cap itself on the
154 command-line, then no secrets are passed through the command line. Then
155 other processes on the system can still see your filenames and other
156 arguments you type there, but not the caps that Tahoe-LAFS uses to permit
157 access to your files and directories.
162 Capabilities may be leaked to web browser phishing filter / "safe browsing" servers
163 -----------------------------------------------------------------------------------
165 Firefox, Internet Explorer, and Chrome include a "phishing filter" or
166 "safe browing" component, which is turned on by default, and which sends
167 any URLs that it deems suspicious to a central server.
169 Microsoft gives `a brief description of their filter's operation`_. Firefox
170 and Chrome both use Google's `"safe browsing API"`_ (`specification`_).
172 This of course has implications for the privacy of general web browsing
173 (especially in the cases of Firefox and Chrome, which send your main
174 personally identifying Google cookie along with these requests without your
175 explicit consent, as described in `Firefox bugzilla ticket #368255`_.
177 The reason for documenting this issue here, though, is that when using the
178 Tahoe-LAFS web user interface, it could also affect confidentiality and integrity
179 by leaking capabilities to the filter server.
181 Since IE's filter sends URLs by SSL/TLS, the exposure of caps is limited to
182 the filter server operators (or anyone able to hack the filter server) rather
183 than to network eavesdroppers. The "safe browsing API" protocol used by
184 Firefox and Chrome, on the other hand, is *not* encrypted, although the
185 URL components are normally hashed.
187 Opera also has a similar facility that is disabled by default. A previous
188 version of this file stated that Firefox had abandoned their phishing
189 filter; this was incorrect.
191 .. _a brief description of their filter's operation: http://blogs.msdn.com/ie/archive/2005/09/09/463204.aspx
192 .. _"safe browsing API": http://code.google.com/apis/safebrowsing/
193 .. _specification: http://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec
194 .. _Firefox bugzilla ticket #368255: https://bugzilla.mozilla.org/show_bug.cgi?id=368255
199 If you use any phishing filter or "safe browsing" feature, consider either
200 disabling it, or not using the WUI via that browser. Phishing filters have
201 `very limited effectiveness`_ , and phishing or malware attackers have learnt
204 .. _very limited effectiveness: http://lorrie.cranor.org/pubs/ndss-phish-tools-final.pdf
206 To disable the filter in IE7 or IE8:
207 ++++++++++++++++++++++++++++++++++++
209 - Click Internet Options from the Tools menu.
211 - Click the Advanced tab.
213 - If an "Enable SmartScreen Filter" option is present, uncheck it.
214 If a "Use Phishing Filter" or "Phishing Filter" option is present,
217 - Confirm (click OK or Yes) out of all dialogs.
219 If you have a version of IE that splits the settings between security
220 zones, do this for all zones.
222 To disable the filter in Firefox:
223 +++++++++++++++++++++++++++++++++
225 - Click Options from the Tools menu.
227 - Click the Security tab.
229 - Uncheck both the "Block reported attack sites" and "Block reported
230 web forgeries" options.
234 To disable the filter in Chrome:
235 ++++++++++++++++++++++++++++++++
237 - Click Options from the Tools menu.
239 - Click the "Under the Hood" tab and find the "Privacy" section.
241 - Uncheck the "Enable phishing and malware protection" option.
248 Known issues in the FTP and SFTP frontends
249 ------------------------------------------
251 These are documented in `docs/frontends/FTP-and-SFTP.rst`_ and on `the SftpFrontend page`_ on the wiki.
253 .. _docs/frontends/FTP-and-SFTP.rst: frontends/FTP-and-SFTP.rst
254 .. _the SftpFrontend page: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/SftpFrontend
259 Traffic analysis based on sizes of files/directories, storage indices, and timing
260 ---------------------------------------------------------------------------------
262 Files and directories stored by Tahoe-LAFS are encrypted, but the ciphertext
263 reveals the exact size of the original file or directory representation.
264 This information is available to passive eavesdroppers and to server operators.
266 For example, a large data set with known file sizes could probably be
267 identified with a high degree of confidence.
269 Uploads and downloads of the same file or directory can be linked by server
270 operators, even without making assumptions based on file size. Anyone who
271 knows the introducer furl for a grid may be able to act as a server operator.
272 This implies that if such an attacker knows which file/directory is being
273 accessed in a particular request (by some other form of surveillance, say),
274 then they can identify later or earlier accesses of the same file/directory.
276 Observing requests during a directory traversal (such as a deep-check
277 operation) could reveal information about the directory structure, i.e.
278 which files and subdirectories are linked from a given directory.
280 Attackers can combine the above information with inferences based on timing
281 correlations. For instance, two files that are accessed close together in
282 time are likely to be related even if they are not linked in the directory
283 structure. Also, users that access the same files may be related to each other.
288 Known Issues in Tahoe-LAFS v1.8.2, released 30-Jan-2011
289 =======================================================
292 Unauthorized deletion of an immutable file by its storage index
293 ---------------------------------------------------------------
295 Due to a flaw in the Tahoe-LAFS storage server software in v1.3.0 through
296 v1.8.2, a person who knows the "storage index" that identifies an immutable
297 file can cause the server to delete its shares of that file.
299 If an attacker can cause enough shares to be deleted from enough storage
300 servers, this deletes the file.
302 This vulnerability does not enable anyone to read file contents without
303 authorization (confidentiality), nor to change the contents of a file
306 A person could learn the storage index of a file in several ways:
308 1. By being granted the authority to read the immutable file—i.e. by being
309 granted a read capability to the file. They can determine the file's
310 storage index from its read capability.
312 2. By being granted a verify capability to the file. They can determine the
313 file's storage index from its verify capability. This case probably
314 doesn't happen often because users typically don't share verify caps.
316 3. By operating a storage server, and receiving a request from a client that
317 has a read cap or a verify cap. If the client attempts to upload,
318 download, or verify the file with their storage server, even if it doesn't
319 actually have the file, then they can learn the storage index of the file.
321 4. By gaining read access to an existing storage server's local filesystem,
322 and inspecting the directory structure that it stores its shares in. They
323 can thus learn the storage indexes of all files that the server is holding
324 at least one share of. Normally only the operator of an existing storage
325 server would be able to inspect its local filesystem, so this requires
326 either being such an operator of an existing storage server, or somehow
327 gaining the ability to inspect the local filesystem of an existing storage
332 Tahoe-LAFS version v1.8.3 or newer (except v1.9a1) no longer has this flaw;
333 if you upgrade a storage server to a fixed release then that server is no
334 longer vulnerable to this problem.
336 Note that the issue is local to each storage server independently of other
337 storage servers—when you upgrade a storage server then that particular
338 storage server can no longer be tricked into deleting its shares of the
341 If you can't immediately upgrade your storage server to a version of
342 Tahoe-LAFS that eliminates this vulnerability, then you could temporarily
343 shut down your storage server. This would of course negatively impact
344 availability—clients would not be able to upload or download shares to that
345 particular storage server while it was shut down—but it would protect the
346 shares already stored on that server from being deleted as long as the server
349 If the servers that store shares of your file are running a version of
350 Tahoe-LAFS with this vulnerability, then you should think about whether
351 someone can learn the storage indexes of your files by one of the methods
352 described above. A person can not exploit this vulnerability unless they have
353 received a read cap or verify cap, or they control a storage server that has
354 been queried about this file by a client that has a read cap or a verify cap.
356 Tahoe-LAFS does not currently have a mechanism to limit which storage servers
357 can connect to your grid, but it does have a way to see which storage servers
358 have been connected to the grid. The Introducer's front page in the Web User
359 Interface has a list of all storage servers that the Introducer has ever seen
360 and the first time and the most recent time that it saw them. Each Tahoe-LAFS
361 gateway maintains a similar list on its front page in its Web User Interface,
362 showing all of the storage servers that it learned about from the Introducer,
363 when it first connected to that storage server, and when it most recently
364 connected to that storage server. These lists are stored in memory and are
365 reset to empty when the process is restarted.
367 See ticket `#1528`_ for technical details.
369 .. _#1528: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1528