2013-11-08 20:31:08 +00:00
|
|
|
.. -*- coding: utf-8-with-signature -*-
|
|
|
|
|
2013-10-05 03:29:00 +00:00
|
|
|
See also `cautions.rst`_.
|
2012-04-01 21:40:39 +00:00
|
|
|
|
2013-10-05 03:29:00 +00:00
|
|
|
.. _cautions.rst: cautions.rst
|
2012-04-01 21:40:39 +00:00
|
|
|
|
2011-09-14 06:47:28 +00:00
|
|
|
============
|
2011-09-14 05:54:19 +00:00
|
|
|
Known Issues
|
|
|
|
============
|
2011-09-14 05:16:39 +00:00
|
|
|
|
2008-12-30 07:52:26 +00:00
|
|
|
Below is a list of known issues in recent releases of Tahoe-LAFS, and how to
|
|
|
|
manage them. The current version of this file can be found at
|
2011-10-29 18:39:46 +00:00
|
|
|
https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/known_issues.rst .
|
2008-07-22 01:02:49 +00:00
|
|
|
|
2009-08-02 02:57:10 +00:00
|
|
|
If you've been using Tahoe-LAFS since v1.1 (released 2008-06-11) or if you're
|
2009-07-21 23:43:11 +00:00
|
|
|
just curious about what sort of mistakes we've made in the past, then you might
|
2011-09-14 05:54:19 +00:00
|
|
|
want to read `the "historical known issues" document`_.
|
|
|
|
|
|
|
|
.. _the "historical known issues" document: historical/historical_known_issues.txt
|
|
|
|
|
2008-12-30 07:52:26 +00:00
|
|
|
|
2013-04-25 00:17:45 +00:00
|
|
|
Known Issues in Tahoe-LAFS v1.10, released 01-May-2013
|
2012-07-01 23:19:21 +00:00
|
|
|
======================================================
|
2011-09-14 05:02:40 +00:00
|
|
|
|
2011-11-18 00:20:13 +00:00
|
|
|
* `Unauthorized access by JavaScript in unrelated files`_
|
|
|
|
* `Disclosure of file through embedded hyperlinks or JavaScript in that file`_
|
2011-09-14 05:02:40 +00:00
|
|
|
* `Command-line arguments are leaked to other local users`_
|
|
|
|
* `Capabilities may be leaked to web browser phishing filter / "safe browsing" servers`_
|
|
|
|
* `Known issues in the FTP and SFTP frontends`_
|
2011-09-14 05:16:39 +00:00
|
|
|
* `Traffic analysis based on sizes of files/directories, storage indices, and timing`_
|
2013-04-15 05:27:03 +00:00
|
|
|
* `Privacy leak via Google Chart API link in map-update timing web page`_
|
2009-02-11 21:14:53 +00:00
|
|
|
|
2011-09-14 05:54:19 +00:00
|
|
|
----
|
|
|
|
|
2011-11-18 00:00:30 +00:00
|
|
|
Unauthorized access by JavaScript in unrelated files
|
2011-11-18 00:20:13 +00:00
|
|
|
----------------------------------------------------
|
2009-02-11 21:14:53 +00:00
|
|
|
|
2009-08-02 02:57:10 +00:00
|
|
|
If you view a file stored in Tahoe-LAFS through a web user interface,
|
2011-11-18 00:00:30 +00:00
|
|
|
JavaScript embedded in that file can, in some circumstances, access other
|
|
|
|
files or directories stored in Tahoe-LAFS that you view through the same
|
|
|
|
web user interface. Such a script would be able to send the contents of
|
2009-08-02 02:57:10 +00:00
|
|
|
those other files or directories to the author of the script, and if you
|
|
|
|
have the ability to modify the contents of those files or directories,
|
|
|
|
then that script could modify or delete those files or directories.
|
2009-02-11 21:14:53 +00:00
|
|
|
|
2011-11-18 00:20:13 +00:00
|
|
|
This attack is known to be possible when an attacking tab or window could
|
|
|
|
reach a tab or window containing a Tahoe URI by navigating back or forward
|
|
|
|
in the history, either from itself or from any frame with a known name (as
|
|
|
|
specified by the "target" attribute of an HTML link). It might be possible
|
|
|
|
in other cases depending on the browser.
|
|
|
|
|
2011-09-14 05:54:19 +00:00
|
|
|
*how to manage it*
|
2009-02-13 05:16:21 +00:00
|
|
|
|
2009-08-02 02:57:10 +00:00
|
|
|
For future versions of Tahoe-LAFS, we are considering ways to close off
|
|
|
|
this leakage of authority while preserving ease of use -- the discussion
|
2011-09-14 05:54:19 +00:00
|
|
|
of this issue is ticket `#615`_.
|
2009-02-11 21:14:53 +00:00
|
|
|
|
2009-08-02 02:57:10 +00:00
|
|
|
For the present, either do not view files stored in Tahoe-LAFS through a
|
|
|
|
web user interface, or turn off JavaScript in your web browser before
|
|
|
|
doing so, or limit your viewing to files which you know don't contain
|
2009-02-13 05:16:21 +00:00
|
|
|
malicious JavaScript.
|
2008-07-22 01:02:49 +00:00
|
|
|
|
2011-10-29 18:39:46 +00:00
|
|
|
.. _#615: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/615
|
2011-09-14 05:54:19 +00:00
|
|
|
|
|
|
|
|
|
|
|
----
|
2009-02-13 05:16:21 +00:00
|
|
|
|
2011-11-18 00:20:13 +00:00
|
|
|
Disclosure of file through embedded hyperlinks or JavaScript in that file
|
|
|
|
-------------------------------------------------------------------------
|
2008-12-30 08:01:16 +00:00
|
|
|
|
2009-08-02 02:57:10 +00:00
|
|
|
If there is a file stored on a Tahoe-LAFS storage grid, and that file
|
|
|
|
gets downloaded and displayed in a web browser, then JavaScript or
|
2008-12-30 08:01:16 +00:00
|
|
|
hyperlinks within that file can leak the capability to that file to a
|
|
|
|
third party, which means that third party gets access to the file.
|
|
|
|
|
|
|
|
If there is JavaScript in the file, then it could deliberately leak
|
|
|
|
the capability to the file out to some remote listener.
|
|
|
|
|
|
|
|
If there are hyperlinks in the file, and they get followed, then
|
|
|
|
whichever server they point to receives the capability to the
|
|
|
|
file. Note that IMG tags are typically followed automatically by web
|
|
|
|
browsers, so being careful which hyperlinks you click on is not
|
|
|
|
sufficient to prevent this from happening.
|
|
|
|
|
2011-09-14 05:54:19 +00:00
|
|
|
*how to manage it*
|
2008-12-30 08:01:16 +00:00
|
|
|
|
2009-08-02 02:57:10 +00:00
|
|
|
For future versions of Tahoe-LAFS, we are considering ways to close off
|
|
|
|
this leakage of authority while preserving ease of use -- the discussion
|
2011-09-14 05:54:19 +00:00
|
|
|
of this issue is ticket `#127`_.
|
2008-12-30 08:01:16 +00:00
|
|
|
|
|
|
|
For the present, a good work-around is that if you want to store and
|
2009-08-02 02:57:10 +00:00
|
|
|
view a file on Tahoe-LAFS and you want that file to remain private, then
|
|
|
|
remove from that file any hyperlinks pointing to other people's servers
|
|
|
|
and remove any JavaScript unless you are sure that the JavaScript is not
|
|
|
|
written to maliciously leak access.
|
2008-12-30 08:01:16 +00:00
|
|
|
|
2011-10-29 18:39:46 +00:00
|
|
|
.. _#127: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/127
|
2011-09-14 05:54:19 +00:00
|
|
|
|
|
|
|
|
|
|
|
----
|
2008-12-30 08:01:16 +00:00
|
|
|
|
2010-10-15 05:29:13 +00:00
|
|
|
Command-line arguments are leaked to other local users
|
|
|
|
------------------------------------------------------
|
2008-07-22 01:02:49 +00:00
|
|
|
|
2009-08-02 02:57:10 +00:00
|
|
|
Remember that command-line arguments are visible to other users (through
|
|
|
|
the 'ps' command, or the windows Process Explorer tool), so if you are
|
|
|
|
using a Tahoe-LAFS node on a shared host, other users on that host will
|
|
|
|
be able to see (and copy) any caps that you pass as command-line
|
|
|
|
arguments. This includes directory caps that you set up with the "tahoe
|
2010-06-19 05:17:34 +00:00
|
|
|
add-alias" command.
|
2008-07-22 01:02:49 +00:00
|
|
|
|
2011-09-14 05:54:19 +00:00
|
|
|
*how to manage it*
|
2010-06-19 05:17:34 +00:00
|
|
|
|
|
|
|
As of Tahoe-LAFS v1.3.0 there is a "tahoe create-alias" command that does
|
|
|
|
the following technique for you.
|
2008-07-22 01:02:49 +00:00
|
|
|
|
2009-08-02 02:57:10 +00:00
|
|
|
Bypass add-alias and edit the NODEDIR/private/aliases file directly, by
|
|
|
|
adding a line like this:
|
2008-07-22 01:02:49 +00:00
|
|
|
|
2010-10-15 05:29:13 +00:00
|
|
|
fun: URI:DIR2:ovjy4yhylqlfoqg2vcze36dhde:4d4f47qko2xm5g7osgo2yyidi5m4muyo2vjjy53q4vjju2u55mfa
|
2008-07-22 01:02:49 +00:00
|
|
|
|
2009-08-02 02:57:10 +00:00
|
|
|
By entering the dircap through the editor, the command-line arguments
|
|
|
|
are bypassed, and other users will not be able to see them. Once you've
|
|
|
|
added the alias, if you use that alias instead of a cap itself on the
|
|
|
|
command-line, then no secrets are passed through the command line. Then
|
|
|
|
other processes on the system can still see your filenames and other
|
2010-06-19 05:17:34 +00:00
|
|
|
arguments you type there, but not the caps that Tahoe-LAFS uses to permit
|
|
|
|
access to your files and directories.
|
|
|
|
|
|
|
|
|
2011-09-14 05:54:19 +00:00
|
|
|
----
|
|
|
|
|
2010-10-15 05:29:13 +00:00
|
|
|
Capabilities may be leaked to web browser phishing filter / "safe browsing" servers
|
|
|
|
-----------------------------------------------------------------------------------
|
2010-06-19 05:17:34 +00:00
|
|
|
|
|
|
|
Firefox, Internet Explorer, and Chrome include a "phishing filter" or
|
|
|
|
"safe browing" component, which is turned on by default, and which sends
|
|
|
|
any URLs that it deems suspicious to a central server.
|
|
|
|
|
2011-09-14 05:54:19 +00:00
|
|
|
Microsoft gives `a brief description of their filter's operation`_. Firefox
|
|
|
|
and Chrome both use Google's `"safe browsing API"`_ (`specification`_).
|
2010-06-19 05:17:34 +00:00
|
|
|
|
|
|
|
This of course has implications for the privacy of general web browsing
|
|
|
|
(especially in the cases of Firefox and Chrome, which send your main
|
2011-09-14 05:54:19 +00:00
|
|
|
personally identifying Google cookie along with these requests without your
|
|
|
|
explicit consent, as described in `Firefox bugzilla ticket #368255`_.
|
2010-06-19 05:17:34 +00:00
|
|
|
|
|
|
|
The reason for documenting this issue here, though, is that when using the
|
|
|
|
Tahoe-LAFS web user interface, it could also affect confidentiality and integrity
|
|
|
|
by leaking capabilities to the filter server.
|
|
|
|
|
|
|
|
Since IE's filter sends URLs by SSL/TLS, the exposure of caps is limited to
|
|
|
|
the filter server operators (or anyone able to hack the filter server) rather
|
|
|
|
than to network eavesdroppers. The "safe browsing API" protocol used by
|
|
|
|
Firefox and Chrome, on the other hand, is *not* encrypted, although the
|
|
|
|
URL components are normally hashed.
|
|
|
|
|
|
|
|
Opera also has a similar facility that is disabled by default. A previous
|
|
|
|
version of this file stated that Firefox had abandoned their phishing
|
|
|
|
filter; this was incorrect.
|
|
|
|
|
2012-03-13 20:26:54 +00:00
|
|
|
.. _a brief description of their filter's operation: https://blogs.msdn.com/ie/archive/2005/09/09/463204.aspx
|
|
|
|
.. _"safe browsing API": https://code.google.com/apis/safebrowsing/
|
|
|
|
.. _specification: https://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec
|
2011-09-14 05:54:19 +00:00
|
|
|
.. _Firefox bugzilla ticket #368255: https://bugzilla.mozilla.org/show_bug.cgi?id=368255
|
|
|
|
|
|
|
|
|
|
|
|
*how to manage it*
|
2010-06-19 05:17:34 +00:00
|
|
|
|
|
|
|
If you use any phishing filter or "safe browsing" feature, consider either
|
|
|
|
disabling it, or not using the WUI via that browser. Phishing filters have
|
2011-09-14 05:54:19 +00:00
|
|
|
`very limited effectiveness`_ , and phishing or malware attackers have learnt
|
|
|
|
how to bypass them.
|
|
|
|
|
|
|
|
.. _very limited effectiveness: http://lorrie.cranor.org/pubs/ndss-phish-tools-final.pdf
|
2010-02-02 01:52:38 +00:00
|
|
|
|
|
|
|
To disable the filter in IE7 or IE8:
|
2011-09-14 05:02:40 +00:00
|
|
|
++++++++++++++++++++++++++++++++++++
|
2010-10-15 05:29:13 +00:00
|
|
|
|
|
|
|
- Click Internet Options from the Tools menu.
|
|
|
|
|
|
|
|
- Click the Advanced tab.
|
|
|
|
|
|
|
|
- If an "Enable SmartScreen Filter" option is present, uncheck it.
|
|
|
|
If a "Use Phishing Filter" or "Phishing Filter" option is present,
|
|
|
|
set it to Disable.
|
|
|
|
|
|
|
|
- Confirm (click OK or Yes) out of all dialogs.
|
2010-02-02 01:52:38 +00:00
|
|
|
|
|
|
|
If you have a version of IE that splits the settings between security
|
2010-06-19 05:17:34 +00:00
|
|
|
zones, do this for all zones.
|
|
|
|
|
|
|
|
To disable the filter in Firefox:
|
2011-09-14 05:02:40 +00:00
|
|
|
+++++++++++++++++++++++++++++++++
|
2010-10-15 05:29:13 +00:00
|
|
|
|
|
|
|
- Click Options from the Tools menu.
|
|
|
|
|
|
|
|
- Click the Security tab.
|
|
|
|
|
|
|
|
- Uncheck both the "Block reported attack sites" and "Block reported
|
|
|
|
web forgeries" options.
|
|
|
|
|
|
|
|
- Click OK.
|
2010-06-19 05:17:34 +00:00
|
|
|
|
|
|
|
To disable the filter in Chrome:
|
2011-09-14 05:02:40 +00:00
|
|
|
++++++++++++++++++++++++++++++++
|
2010-10-15 05:29:13 +00:00
|
|
|
|
|
|
|
- Click Options from the Tools menu.
|
|
|
|
|
|
|
|
- Click the "Under the Hood" tab and find the "Privacy" section.
|
|
|
|
|
|
|
|
- Uncheck the "Enable phishing and malware protection" option.
|
|
|
|
|
|
|
|
- Click Close.
|
2010-06-19 05:17:34 +00:00
|
|
|
|
|
|
|
|
2011-09-14 05:54:19 +00:00
|
|
|
----
|
|
|
|
|
2010-10-15 05:29:13 +00:00
|
|
|
Known issues in the FTP and SFTP frontends
|
|
|
|
------------------------------------------
|
2010-06-19 05:17:34 +00:00
|
|
|
|
2011-09-14 05:54:19 +00:00
|
|
|
These are documented in `docs/frontends/FTP-and-SFTP.rst`_ and on `the SftpFrontend page`_ on the wiki.
|
|
|
|
|
|
|
|
.. _docs/frontends/FTP-and-SFTP.rst: frontends/FTP-and-SFTP.rst
|
2011-10-29 18:39:46 +00:00
|
|
|
.. _the SftpFrontend page: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/SftpFrontend
|
2011-09-14 05:54:19 +00:00
|
|
|
|
2010-10-24 23:42:59 +00:00
|
|
|
|
2011-09-14 05:54:19 +00:00
|
|
|
----
|
2010-10-24 23:42:59 +00:00
|
|
|
|
|
|
|
Traffic analysis based on sizes of files/directories, storage indices, and timing
|
|
|
|
---------------------------------------------------------------------------------
|
|
|
|
|
|
|
|
Files and directories stored by Tahoe-LAFS are encrypted, but the ciphertext
|
|
|
|
reveals the exact size of the original file or directory representation.
|
|
|
|
This information is available to passive eavesdroppers and to server operators.
|
|
|
|
|
|
|
|
For example, a large data set with known file sizes could probably be
|
|
|
|
identified with a high degree of confidence.
|
|
|
|
|
|
|
|
Uploads and downloads of the same file or directory can be linked by server
|
|
|
|
operators, even without making assumptions based on file size. Anyone who
|
|
|
|
knows the introducer furl for a grid may be able to act as a server operator.
|
|
|
|
This implies that if such an attacker knows which file/directory is being
|
|
|
|
accessed in a particular request (by some other form of surveillance, say),
|
|
|
|
then they can identify later or earlier accesses of the same file/directory.
|
|
|
|
|
|
|
|
Observing requests during a directory traversal (such as a deep-check
|
|
|
|
operation) could reveal information about the directory structure, i.e.
|
|
|
|
which files and subdirectories are linked from a given directory.
|
|
|
|
|
|
|
|
Attackers can combine the above information with inferences based on timing
|
|
|
|
correlations. For instance, two files that are accessed close together in
|
|
|
|
time are likely to be related even if they are not linked in the directory
|
|
|
|
structure. Also, users that access the same files may be related to each other.
|
2011-10-31 05:08:31 +00:00
|
|
|
|
|
|
|
|
2013-04-15 05:27:03 +00:00
|
|
|
----
|
|
|
|
|
|
|
|
Privacy leak via Google Chart API link in map-update timing web page
|
|
|
|
--------------------------------------------------------------------
|
|
|
|
|
|
|
|
The Tahoe web-based user interface includes a diagnostic page known as the
|
|
|
|
"map-update timing page". It is reached through the "Recent and Active
|
|
|
|
Operations" link on the front welcome page, then through the "Status" column
|
|
|
|
for "map-update" operations (which occur when mutable files, including
|
|
|
|
directories, are read or written). This page contains per-server response
|
|
|
|
times, as lines of text, and includes an image which displays the response
|
2013-10-05 03:29:00 +00:00
|
|
|
times in graphical form. The image is generated by constructing a URL for
|
|
|
|
the `Google Chart API`_, which is then served by the `chart.apis.google.com`
|
|
|
|
internet server.
|
|
|
|
|
|
|
|
.. _Google Chart API: https://developers.google.com/chart/image/
|
2013-04-15 05:27:03 +00:00
|
|
|
|
|
|
|
When you view this page, several parties may learn information about your
|
|
|
|
Tahoe activities. The request will typically include a "Referer" header,
|
|
|
|
revealing the URL of the mapupdate status page (which is typically something
|
|
|
|
like "http://127.0.0.1:3456/status/mapupdate-123") to network observers and
|
|
|
|
the Google API server. The image returned by this server is typically a PNG
|
|
|
|
file, but either the server or a MitM attacker could replace it with
|
|
|
|
something malicious that attempts to exploit a browser rendering bug or
|
|
|
|
buffer overflow. (Note that browsers do not execute scripts inside IMG tags,
|
|
|
|
even for SVG images).
|
|
|
|
|
|
|
|
In addition, if your Tahoe node connects to its grid over Tor or i2p, but the
|
2013-04-23 23:39:53 +00:00
|
|
|
web browser you use to access your node does not, then this image link may
|
|
|
|
reveal your use of Tahoe (and that grid) to the outside world. It is not
|
|
|
|
recommended to use a browser in this way, because other links in Tahoe-stored
|
|
|
|
content would reveal even more information (e.g. an attacker could store an
|
|
|
|
HTML file with unique CSS references into a shared Tahoe grid, then send your
|
|
|
|
pseudonym a message with its URI, then observe your browser loading that CSS
|
|
|
|
file, and thus link the source IP address of your web client to that
|
|
|
|
pseudonym).
|
2013-04-15 05:27:03 +00:00
|
|
|
|
|
|
|
A future version of Tahoe will probably replace the Google Chart API link
|
|
|
|
(which was deprecated by Google in April 2012) with client-side javascript
|
|
|
|
using d3.js, removing the information leak but requiring JS to see the chart.
|
|
|
|
See ticket `#1942`_ for details.
|
|
|
|
|
|
|
|
.. _#1942: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1942
|
|
|
|
|
2012-01-12 21:35:53 +00:00
|
|
|
----
|
|
|
|
|
|
|
|
Known Issues in Tahoe-LAFS v1.9.0, released 31-Oct-2011
|
|
|
|
=======================================================
|
|
|
|
|
|
|
|
|
|
|
|
Integrity Failure during Mutable Downloads
|
|
|
|
------------------------------------------
|
|
|
|
|
|
|
|
Under certain circumstances, the integrity-verification code of the mutable
|
|
|
|
downloader could be bypassed. Clients who receive carefully crafted shares
|
|
|
|
(from attackers) will emit incorrect file contents, and the usual
|
|
|
|
share-corruption errors would not be raised. This only affects mutable files
|
|
|
|
(not immutable), and only affects downloads that use doctored shares. It is
|
|
|
|
not persistent: the threat is resolved once you upgrade your client to a
|
|
|
|
version without the bug. However, read-modify-write operations (such as
|
|
|
|
directory manipulations) performed by vulnerable clients could cause the
|
|
|
|
attacker's modifications to be written back out to the mutable file, making
|
|
|
|
the corruption permanent.
|
|
|
|
|
|
|
|
The attacker's ability to manipulate the file contents is limited. They can
|
|
|
|
modify FEC-encoded ciphertext in all but one share. This gives them the
|
|
|
|
ability to blindly flip bits in roughly 2/3rds of the file (for the default
|
|
|
|
k=3 encoding parameter). Confidentiality remains intact, unless the attacker
|
|
|
|
can deduce the file's contents by observing your reactions to corrupted
|
|
|
|
downloads.
|
|
|
|
|
|
|
|
This bug was introduced in 1.9.0, as part of the MDMF-capable downloader, and
|
|
|
|
affects both SDMF and MDMF files. It was not present in 1.8.3.
|
|
|
|
|
|
|
|
*how to manage it*
|
|
|
|
|
|
|
|
There are three options:
|
|
|
|
|
|
|
|
* Upgrade to 1.9.1, which fixes the bug
|
|
|
|
* Downgrade to 1.8.3, which does not contain the bug
|
|
|
|
* If using 1.9.0, do not trust the contents of mutable files (whether SDMF or
|
|
|
|
MDMF) that the 1.9.0 client emits, and do not modify directories (which
|
|
|
|
could write the corrupted data back into place, making the damage
|
|
|
|
persistent)
|
|
|
|
|
2011-10-31 05:22:52 +00:00
|
|
|
----
|
|
|
|
|
2011-10-31 05:08:31 +00:00
|
|
|
Known Issues in Tahoe-LAFS v1.8.2, released 30-Jan-2011
|
|
|
|
=======================================================
|
|
|
|
|
|
|
|
|
|
|
|
Unauthorized deletion of an immutable file by its storage index
|
|
|
|
---------------------------------------------------------------
|
|
|
|
|
|
|
|
Due to a flaw in the Tahoe-LAFS storage server software in v1.3.0 through
|
|
|
|
v1.8.2, a person who knows the "storage index" that identifies an immutable
|
|
|
|
file can cause the server to delete its shares of that file.
|
|
|
|
|
|
|
|
If an attacker can cause enough shares to be deleted from enough storage
|
|
|
|
servers, this deletes the file.
|
|
|
|
|
|
|
|
This vulnerability does not enable anyone to read file contents without
|
|
|
|
authorization (confidentiality), nor to change the contents of a file
|
|
|
|
(integrity).
|
|
|
|
|
|
|
|
A person could learn the storage index of a file in several ways:
|
|
|
|
|
2013-04-09 19:19:58 +00:00
|
|
|
1. By being granted the authority to read the immutable file: i.e. by being
|
2011-10-31 05:08:31 +00:00
|
|
|
granted a read capability to the file. They can determine the file's
|
|
|
|
storage index from its read capability.
|
|
|
|
|
|
|
|
2. By being granted a verify capability to the file. They can determine the
|
|
|
|
file's storage index from its verify capability. This case probably
|
|
|
|
doesn't happen often because users typically don't share verify caps.
|
|
|
|
|
|
|
|
3. By operating a storage server, and receiving a request from a client that
|
|
|
|
has a read cap or a verify cap. If the client attempts to upload,
|
|
|
|
download, or verify the file with their storage server, even if it doesn't
|
|
|
|
actually have the file, then they can learn the storage index of the file.
|
|
|
|
|
|
|
|
4. By gaining read access to an existing storage server's local filesystem,
|
|
|
|
and inspecting the directory structure that it stores its shares in. They
|
|
|
|
can thus learn the storage indexes of all files that the server is holding
|
|
|
|
at least one share of. Normally only the operator of an existing storage
|
|
|
|
server would be able to inspect its local filesystem, so this requires
|
|
|
|
either being such an operator of an existing storage server, or somehow
|
|
|
|
gaining the ability to inspect the local filesystem of an existing storage
|
|
|
|
server.
|
|
|
|
|
|
|
|
*how to manage it*
|
|
|
|
|
|
|
|
Tahoe-LAFS version v1.8.3 or newer (except v1.9a1) no longer has this flaw;
|
|
|
|
if you upgrade a storage server to a fixed release then that server is no
|
|
|
|
longer vulnerable to this problem.
|
|
|
|
|
|
|
|
Note that the issue is local to each storage server independently of other
|
2013-04-09 19:19:58 +00:00
|
|
|
storage servers: when you upgrade a storage server then that particular
|
2011-10-31 05:08:31 +00:00
|
|
|
storage server can no longer be tricked into deleting its shares of the
|
|
|
|
target file.
|
|
|
|
|
|
|
|
If you can't immediately upgrade your storage server to a version of
|
|
|
|
Tahoe-LAFS that eliminates this vulnerability, then you could temporarily
|
|
|
|
shut down your storage server. This would of course negatively impact
|
2013-04-09 19:19:58 +00:00
|
|
|
availability -- clients would not be able to upload or download shares to
|
|
|
|
that particular storage server while it was shut down -- but it would protect
|
|
|
|
the shares already stored on that server from being deleted as long as the
|
|
|
|
server is shut down.
|
2011-10-31 05:08:31 +00:00
|
|
|
|
|
|
|
If the servers that store shares of your file are running a version of
|
|
|
|
Tahoe-LAFS with this vulnerability, then you should think about whether
|
|
|
|
someone can learn the storage indexes of your files by one of the methods
|
|
|
|
described above. A person can not exploit this vulnerability unless they have
|
|
|
|
received a read cap or verify cap, or they control a storage server that has
|
|
|
|
been queried about this file by a client that has a read cap or a verify cap.
|
|
|
|
|
|
|
|
Tahoe-LAFS does not currently have a mechanism to limit which storage servers
|
|
|
|
can connect to your grid, but it does have a way to see which storage servers
|
|
|
|
have been connected to the grid. The Introducer's front page in the Web User
|
|
|
|
Interface has a list of all storage servers that the Introducer has ever seen
|
|
|
|
and the first time and the most recent time that it saw them. Each Tahoe-LAFS
|
|
|
|
gateway maintains a similar list on its front page in its Web User Interface,
|
|
|
|
showing all of the storage servers that it learned about from the Introducer,
|
|
|
|
when it first connected to that storage server, and when it most recently
|
|
|
|
connected to that storage server. These lists are stored in memory and are
|
|
|
|
reset to empty when the process is restarted.
|
|
|
|
|
|
|
|
See ticket `#1528`_ for technical details.
|
|
|
|
|
|
|
|
.. _#1528: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1528
|