source: trunk/docs/known_issues.rst

Last change on this file was ab091e6, checked in by Brian Warner <warner@…>, at 2016-03-30T09:25:27Z

update relnotes and known_issues

  • Property mode set to 100644
File size: 18.4 KB
Line 
1.. -*- coding: utf-8-with-signature -*-
2
3See also :doc:`cautions.rst<cautions>`.
4
5============
6Known Issues
7============
8
9Below is a list of known issues in recent releases of Tahoe-LAFS, and how to
10manage them.  The current version of this file can be found at
11https://github.com/tahoe-lafs/tahoe-lafs/blob/master/docs/known_issues.rst .
12
13If you've been using Tahoe-LAFS since v1.1 (released 2008-06-11) or if you're
14just curious about what sort of mistakes we've made in the past, then you
15might want to read the "historical known issues" document in
16``docs/historical/historical_known_issues.txt``.
17
18
19Known Issues in Tahoe-LAFS v1.10.3, released 30-Mar-2016
20========================================================
21
22  *  `Unauthorized access by JavaScript in unrelated files`_
23  *  `Disclosure of file through embedded hyperlinks or JavaScript in that file`_
24  *  `Command-line arguments are leaked to other local users`_
25  *  `Capabilities may be leaked to web browser phishing filter / "safe browsing" servers`_
26  *  `Known issues in the FTP and SFTP frontends`_
27  *  `Traffic analysis based on sizes of files/directories, storage indices, and timing`_
28  *  `Privacy leak via Google Chart API link in map-update timing web page`_
29
30----
31
32Unauthorized access by JavaScript in unrelated files
33----------------------------------------------------
34
35If you view a file stored in Tahoe-LAFS through a web user interface,
36JavaScript embedded in that file can, in some circumstances, access other
37files or directories stored in Tahoe-LAFS that you view through the same
38web user interface.  Such a script would be able to send the contents of
39those other files or directories to the author of the script, and if you
40have the ability to modify the contents of those files or directories,
41then that script could modify or delete those files or directories.
42
43This attack is known to be possible when an attacking tab or window could
44reach a tab or window containing a Tahoe URI by navigating back or forward
45in the history, either from itself or from any frame with a known name (as
46specified by the "target" attribute of an HTML link). It might be possible
47in other cases depending on the browser.
48
49*how to manage it*
50
51For future versions of Tahoe-LAFS, we are considering ways to close off
52this leakage of authority while preserving ease of use -- the discussion
53of this issue is ticket `#615`_.
54
55For the present, either do not view files stored in Tahoe-LAFS through a
56web user interface, or turn off JavaScript in your web browser before
57doing so, or limit your viewing to files which you know don't contain
58malicious JavaScript.
59
60.. _#615: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/615
61
62
63----
64
65Disclosure of file through embedded hyperlinks or JavaScript in that file
66-------------------------------------------------------------------------
67
68If there is a file stored on a Tahoe-LAFS storage grid, and that file
69gets downloaded and displayed in a web browser, then JavaScript or
70hyperlinks within that file can leak the capability to that file to a
71third party, which means that third party gets access to the file.
72
73If there is JavaScript in the file, then it could deliberately leak
74the capability to the file out to some remote listener.
75
76If there are hyperlinks in the file, and they get followed, then
77whichever server they point to receives the capability to the
78file. Note that IMG tags are typically followed automatically by web
79browsers, so being careful which hyperlinks you click on is not
80sufficient to prevent this from happening.
81
82*how to manage it*
83
84For future versions of Tahoe-LAFS, we are considering ways to close off
85this leakage of authority while preserving ease of use -- the discussion
86of this issue is ticket `#127`_.
87
88For the present, a good work-around is that if you want to store and
89view a file on Tahoe-LAFS and you want that file to remain private, then
90remove from that file any hyperlinks pointing to other people's servers
91and remove any JavaScript unless you are sure that the JavaScript is not
92written to maliciously leak access.
93
94.. _#127: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/127
95
96
97----
98
99Command-line arguments are leaked to other local users
100------------------------------------------------------
101
102Remember that command-line arguments are visible to other users (through
103the 'ps' command, or the windows Process Explorer tool), so if you are
104using a Tahoe-LAFS node on a shared host, other users on that host will
105be able to see (and copy) any caps that you pass as command-line
106arguments.  This includes directory caps that you set up with the "tahoe
107add-alias" command.
108
109*how to manage it*
110
111As of Tahoe-LAFS v1.3.0 there is a "tahoe create-alias" command that does
112the following technique for you.
113
114Bypass add-alias and edit the NODEDIR/private/aliases file directly, by
115adding a line like this:
116
117  fun: URI:DIR2:ovjy4yhylqlfoqg2vcze36dhde:4d4f47qko2xm5g7osgo2yyidi5m4muyo2vjjy53q4vjju2u55mfa
118
119By entering the dircap through the editor, the command-line arguments
120are bypassed, and other users will not be able to see them. Once you've
121added the alias, if you use that alias instead of a cap itself on the
122command-line, then no secrets are passed through the command line.  Then
123other processes on the system can still see your filenames and other
124arguments you type there, but not the caps that Tahoe-LAFS uses to permit
125access to your files and directories.
126
127
128----
129
130Capabilities may be leaked to web browser phishing filter / "safe browsing" servers
131-----------------------------------------------------------------------------------
132
133Firefox, Internet Explorer, and Chrome include a "phishing filter" or
134"safe browing" component, which is turned on by default, and which sends
135any URLs that it deems suspicious to a central server.
136
137Microsoft gives `a brief description of their filter's operation`_. Firefox
138and Chrome both use Google's `"safe browsing API"`_ (`specification`_).
139
140This of course has implications for the privacy of general web browsing
141(especially in the cases of Firefox and Chrome, which send your main
142personally identifying Google cookie along with these requests without your
143explicit consent, as described in `Firefox bugzilla ticket #368255`_.
144
145The reason for documenting this issue here, though, is that when using the
146Tahoe-LAFS web user interface, it could also affect confidentiality and integrity
147by leaking capabilities to the filter server.
148
149Since IE's filter sends URLs by SSL/TLS, the exposure of caps is limited to
150the filter server operators (or anyone able to hack the filter server) rather
151than to network eavesdroppers. The "safe browsing API" protocol used by
152Firefox and Chrome, on the other hand, is *not* encrypted, although the
153URL components are normally hashed.
154
155Opera also has a similar facility that is disabled by default. A previous
156version of this file stated that Firefox had abandoned their phishing
157filter; this was incorrect.
158
159.. _a brief description of their filter's operation: https://blogs.msdn.com/ie/archive/2005/09/09/463204.aspx
160.. _"safe browsing API": https://code.google.com/apis/safebrowsing/
161.. _specification: https://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec
162.. _Firefox bugzilla ticket #368255: https://bugzilla.mozilla.org/show_bug.cgi?id=368255
163
164
165*how to manage it*
166
167If you use any phishing filter or "safe browsing" feature, consider either
168disabling it, or not using the WUI via that browser. Phishing filters have
169`very limited effectiveness`_ , and phishing or malware attackers have learnt
170how to bypass them.
171
172.. _very limited effectiveness: http://lorrie.cranor.org/pubs/ndss-phish-tools-final.pdf
173
174To disable the filter in IE7 or IE8:
175++++++++++++++++++++++++++++++++++++
176
177- Click Internet Options from the Tools menu.
178
179- Click the Advanced tab.
180
181- If an "Enable SmartScreen Filter" option is present, uncheck it.
182  If a "Use Phishing Filter" or "Phishing Filter" option is present,
183  set it to Disable.
184
185- Confirm (click OK or Yes) out of all dialogs.
186
187If you have a version of IE that splits the settings between security
188zones, do this for all zones.
189
190To disable the filter in Firefox:
191+++++++++++++++++++++++++++++++++
192
193- Click Options from the Tools menu.
194
195- Click the Security tab.
196
197- Uncheck both the "Block reported attack sites" and "Block reported
198  web forgeries" options.
199
200- Click OK.
201
202To disable the filter in Chrome:
203++++++++++++++++++++++++++++++++
204
205- Click Options from the Tools menu.
206
207- Click the "Under the Hood" tab and find the "Privacy" section.
208
209- Uncheck the "Enable phishing and malware protection" option.
210
211- Click Close.
212
213
214----
215
216Known issues in the FTP and SFTP frontends
217------------------------------------------
218
219These are documented in :doc:`frontends/FTP-and-SFTP` and on `the
220SftpFrontend page`_ on the wiki.
221
222.. _the SftpFrontend page: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/SftpFrontend
223
224
225----
226
227Traffic analysis based on sizes of files/directories, storage indices, and timing
228---------------------------------------------------------------------------------
229
230Files and directories stored by Tahoe-LAFS are encrypted, but the ciphertext
231reveals the exact size of the original file or directory representation.
232This information is available to passive eavesdroppers and to server operators.
233
234For example, a large data set with known file sizes could probably be
235identified with a high degree of confidence.
236
237Uploads and downloads of the same file or directory can be linked by server
238operators, even without making assumptions based on file size. Anyone who
239knows the introducer furl for a grid may be able to act as a server operator.
240This implies that if such an attacker knows which file/directory is being
241accessed in a particular request (by some other form of surveillance, say),
242then they can identify later or earlier accesses of the same file/directory.
243
244Observing requests during a directory traversal (such as a deep-check
245operation) could reveal information about the directory structure, i.e.
246which files and subdirectories are linked from a given directory.
247
248Attackers can combine the above information with inferences based on timing
249correlations. For instance, two files that are accessed close together in
250time are likely to be related even if they are not linked in the directory
251structure. Also, users that access the same files may be related to each other.
252
253
254----
255
256Privacy leak via Google Chart API link in map-update timing web page
257--------------------------------------------------------------------
258
259The Tahoe web-based user interface includes a diagnostic page known as the
260"map-update timing page". It is reached through the "Recent and Active
261Operations" link on the front welcome page, then through the "Status" column
262for "map-update" operations (which occur when mutable files, including
263directories, are read or written). This page contains per-server response
264times, as lines of text, and includes an image which displays the response
265times in graphical form. The image is generated by constructing a URL for
266the `Google Chart API`_, which is then served by the `chart.apis.google.com`
267internet server.
268
269.. _Google Chart API: https://developers.google.com/chart/image/
270
271When you view this page, several parties may learn information about your
272Tahoe activities. The request will typically include a "Referer" header,
273revealing the URL of the mapupdate status page (which is typically something
274like "http://127.0.0.1:3456/status/mapupdate-123") to network observers and
275the Google API server. The image returned by this server is typically a PNG
276file, but either the server or a MitM attacker could replace it with
277something malicious that attempts to exploit a browser rendering bug or
278buffer overflow. (Note that browsers do not execute scripts inside IMG tags,
279even for SVG images).
280
281In addition, if your Tahoe node connects to its grid over Tor or i2p, but the
282web browser you use to access your node does not, then this image link may
283reveal your use of Tahoe (and that grid) to the outside world. It is not
284recommended to use a browser in this way, because other links in Tahoe-stored
285content would reveal even more information (e.g. an attacker could store an
286HTML file with unique CSS references into a shared Tahoe grid, then send your
287pseudonym a message with its URI, then observe your browser loading that CSS
288file, and thus link the source IP address of your web client to that
289pseudonym).
290
291A future version of Tahoe will probably replace the Google Chart API link
292(which was deprecated by Google in April 2012) with client-side javascript
293using d3.js, removing the information leak but requiring JS to see the chart.
294See ticket `#1942`_ for details.
295
296.. _#1942: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1942
297
298----
299
300Known Issues in Tahoe-LAFS v1.9.0, released 31-Oct-2011
301=======================================================
302
303
304Integrity Failure during Mutable Downloads
305------------------------------------------
306
307Under certain circumstances, the integrity-verification code of the mutable
308downloader could be bypassed. Clients who receive carefully crafted shares
309(from attackers) will emit incorrect file contents, and the usual
310share-corruption errors would not be raised. This only affects mutable files
311(not immutable), and only affects downloads that use doctored shares. It is
312not persistent: the threat is resolved once you upgrade your client to a
313version without the bug. However, read-modify-write operations (such as
314directory manipulations) performed by vulnerable clients could cause the
315attacker's modifications to be written back out to the mutable file, making
316the corruption permanent.
317
318The attacker's ability to manipulate the file contents is limited. They can
319modify FEC-encoded ciphertext in all but one share. This gives them the
320ability to blindly flip bits in roughly 2/3rds of the file (for the default
321k=3 encoding parameter). Confidentiality remains intact, unless the attacker
322can deduce the file's contents by observing your reactions to corrupted
323downloads.
324
325This bug was introduced in 1.9.0, as part of the MDMF-capable downloader, and
326affects both SDMF and MDMF files. It was not present in 1.8.3.
327
328*how to manage it*
329
330There are three options:
331
332* Upgrade to 1.9.1, which fixes the bug
333* Downgrade to 1.8.3, which does not contain the bug
334* If using 1.9.0, do not trust the contents of mutable files (whether SDMF or
335  MDMF) that the 1.9.0 client emits, and do not modify directories (which
336  could write the corrupted data back into place, making the damage
337  persistent)
338
339----
340
341Known Issues in Tahoe-LAFS v1.8.2, released 30-Jan-2011
342=======================================================
343
344
345Unauthorized deletion of an immutable file by its storage index
346---------------------------------------------------------------
347
348Due to a flaw in the Tahoe-LAFS storage server software in v1.3.0 through
349v1.8.2, a person who knows the "storage index" that identifies an immutable
350file can cause the server to delete its shares of that file.
351
352If an attacker can cause enough shares to be deleted from enough storage
353servers, this deletes the file.
354
355This vulnerability does not enable anyone to read file contents without
356authorization (confidentiality), nor to change the contents of a file
357(integrity).
358
359A person could learn the storage index of a file in several ways:
360
3611. By being granted the authority to read the immutable file: i.e. by being
362   granted a read capability to the file. They can determine the file's
363   storage index from its read capability.
364
3652. By being granted a verify capability to the file. They can determine the
366   file's storage index from its verify capability. This case probably
367   doesn't happen often because users typically don't share verify caps.
368
3693. By operating a storage server, and receiving a request from a client that
370   has a read cap or a verify cap. If the client attempts to upload,
371   download, or verify the file with their storage server, even if it doesn't
372   actually have the file, then they can learn the storage index of the file.
373
3744. By gaining read access to an existing storage server's local filesystem,
375   and inspecting the directory structure that it stores its shares in. They
376   can thus learn the storage indexes of all files that the server is holding
377   at least one share of. Normally only the operator of an existing storage
378   server would be able to inspect its local filesystem, so this requires
379   either being such an operator of an existing storage server, or somehow
380   gaining the ability to inspect the local filesystem of an existing storage
381   server.
382
383*how to manage it*
384
385Tahoe-LAFS version v1.8.3 or newer (except v1.9a1) no longer has this flaw;
386if you upgrade a storage server to a fixed release then that server is no
387longer vulnerable to this problem.
388
389Note that the issue is local to each storage server independently of other
390storage servers: when you upgrade a storage server then that particular
391storage server can no longer be tricked into deleting its shares of the
392target file.
393
394If you can't immediately upgrade your storage server to a version of
395Tahoe-LAFS that eliminates this vulnerability, then you could temporarily
396shut down your storage server. This would of course negatively impact
397availability -- clients would not be able to upload or download shares to
398that particular storage server while it was shut down -- but it would protect
399the shares already stored on that server from being deleted as long as the
400server is shut down.
401
402If the servers that store shares of your file are running a version of
403Tahoe-LAFS with this vulnerability, then you should think about whether
404someone can learn the storage indexes of your files by one of the methods
405described above. A person can not exploit this vulnerability unless they have
406received a read cap or verify cap, or they control a storage server that has
407been queried about this file by a client that has a read cap or a verify cap.
408
409Tahoe-LAFS does not currently have a mechanism to limit which storage servers
410can connect to your grid, but it does have a way to see which storage servers
411have been connected to the grid. The Introducer's front page in the Web User
412Interface has a list of all storage servers that the Introducer has ever seen
413and the first time and the most recent time that it saw them. Each Tahoe-LAFS
414gateway maintains a similar list on its front page in its Web User Interface,
415showing all of the storage servers that it learned about from the Introducer,
416when it first connected to that storage server, and when it most recently
417connected to that storage server. These lists are stored in memory and are
418reset to empty when the process is restarted.
419
420See ticket `#1528`_ for technical details.
421
422.. _#1528: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1528
Note: See TracBrowser for help on using the repository browser.