-============
-Known issues
+
============
+Known Issues
+============
+
+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
+http://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/known_issues.rst .
+
+If you've been using Tahoe-LAFS since v1.1 (released 2008-06-11) or if you're
+just curious about what sort of mistakes we've made in the past, then you might
+want to read `the "historical known issues" document`_.
+
+.. _the "historical known issues" document: historical/historical_known_issues.txt
-* `Overview`_
-* `Issues in Tahoe-LAFS v1.8.1, released 2010-11-28`
+Issues in Tahoe-LAFS v1.8.2, released 2011-01-30
+
+ * `Unauthorized deletion of an immutable file by its storage index`_
* `Potential unauthorized access by JavaScript in unrelated files`_
* `Potential disclosure of file through embedded hyperlinks or JavaScript in that file`_
* `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`_
+ * `Traffic analysis based on sizes of files/directories, storage indices, and timing`_
-Overview
-========
+----
-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
-`<http://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/known_issues.rst>`_.
+Unauthorized deletion of an immutable file by its storage index
+---------------------------------------------------------------
-If you've been using Tahoe-LAFS since v1.1 (released 2008-06-11) or if you're
-just curious about what sort of mistakes we've made in the past, then you might
-want to read `the "historical known issues" document
-<historical/historical_known_issues.txt>`_.
+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:
+
+1. By being granted the authority to read the immutable file—i.e. by being
+ 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*
-Issues in Tahoe-LAFS v1.8.1, released 2010-11-28
-================================================
+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
+storage servers—when you upgrade a storage server then that particular
+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
+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.
+
+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: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1528
+
+
+----
Potential unauthorized access by JavaScript in unrelated files
--------------------------------------------------------------
have the ability to modify the contents of those files or directories,
then that script could modify or delete those files or directories.
-how to manage it
-~~~~~~~~~~~~~~~~
+*how to manage it*
For future versions of Tahoe-LAFS, we are considering ways to close off
this leakage of authority while preserving ease of use -- the discussion
-of this issue is ticket `#615 <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/615>`_.
+of this issue is ticket `#615`_.
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
malicious JavaScript.
+.. _#615: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/615
+
+
+----
Potential disclosure of file through embedded hyperlinks or JavaScript in that file
-----------------------------------------------------------------------------------
browsers, so being careful which hyperlinks you click on is not
sufficient to prevent this from happening.
-how to manage it
-~~~~~~~~~~~~~~~~
+*how to manage it*
For future versions of Tahoe-LAFS, we are considering ways to close off
this leakage of authority while preserving ease of use -- the discussion
-of this issue is ticket `#127 <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/127>`_.
+of this issue is ticket `#127`_.
For the present, a good work-around is that if you want to store and
view a file on Tahoe-LAFS and you want that file to remain private, then
and remove any JavaScript unless you are sure that the JavaScript is not
written to maliciously leak access.
+.. _#127: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/127
+
+
+----
Command-line arguments are leaked to other local users
------------------------------------------------------
arguments. This includes directory caps that you set up with the "tahoe
add-alias" command.
-how to manage it
-~~~~~~~~~~~~~~~~
+*how to manage it*
As of Tahoe-LAFS v1.3.0 there is a "tahoe create-alias" command that does
the following technique for you.
access to your files and directories.
+----
+
Capabilities may be leaked to web browser phishing filter / "safe browsing" servers
-----------------------------------------------------------------------------------
"safe browing" component, which is turned on by default, and which sends
any URLs that it deems suspicious to a central server.
-Microsoft gives a brief description of their filter's operation at
-`<http://blogs.msdn.com/ie/archive/2005/09/09/463204.aspx>`_. Firefox
-and Chrome both use Google's "safe browsing API" which is documented
-at `<http://code.google.com/apis/safebrowsing/>`_ and
-`<http://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec>`_.
+Microsoft gives `a brief description of their filter's operation`_. Firefox
+and Chrome both use Google's `"safe browsing API"`_ (`specification`_).
This of course has implications for the privacy of general web browsing
(especially in the cases of Firefox and Chrome, which send your main
-personally identifying Google cookie along with these requests without
-your explicit consent, as described in `Firefox bugzilla ticket #368255
-<https://bugzilla.mozilla.org/show_bug.cgi?id=368255>`_).
+personally identifying Google cookie along with these requests without your
+explicit consent, as described in `Firefox bugzilla ticket #368255`_.
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
version of this file stated that Firefox had abandoned their phishing
filter; this was incorrect.
-how to manage it
-~~~~~~~~~~~~~~~~
+.. _a brief description of their filter's operation: http://blogs.msdn.com/ie/archive/2005/09/09/463204.aspx
+.. _"safe browsing API": http://code.google.com/apis/safebrowsing/
+.. _specification: http://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec
+.. _Firefox bugzilla ticket #368255: https://bugzilla.mozilla.org/show_bug.cgi?id=368255
+
+
+*how to manage it*
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
-very limited effectiveness (see
-<http://lorrie.cranor.org/pubs/ndss-phish-tools-final.pdf>), and phishing
-or malware attackers have learnt how to bypass them.
+`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
To disable the filter in IE7 or IE8:
-````````````````````````````````````
+++++++++++++++++++++++++++++++++++++
- Click Internet Options from the Tools menu.
zones, do this for all zones.
To disable the filter in Firefox:
-`````````````````````````````````
++++++++++++++++++++++++++++++++++
- Click Options from the Tools menu.
- Click OK.
To disable the filter in Chrome:
-````````````````````````````````
+++++++++++++++++++++++++++++++++
- Click Options from the Tools menu.
- Click Close.
+----
+
Known issues in the FTP and SFTP frontends
------------------------------------------
-These are documented in `docs/frontends/FTP-and-SFTP.rst <frontends/FTP-and-SFTP.rst>`_
-and at `<http://tahoe-lafs.org/trac/tahoe-lafs/wiki/SftpFrontend>`_.
+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
+.. _the SftpFrontend page: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/SftpFrontend
+
+----
Traffic analysis based on sizes of files/directories, storage indices, and timing
---------------------------------------------------------------------------------
projects / tahoe-lafs / tahoe-lafs.git / blobdiff