-============
-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
+<historical/historical_known_issues.txt>`_.
-* `Overview`_
-* `Issues in Tahoe-LAFS v1.8.0, released 2010-09-23`
+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`_
-Overview
-========
+Unauthorized deletion of an immutable file by its storage index
+---------------------------------------------------------------
-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
+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.
-http://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/known_issues.txt
+If an attacker can cause enough shares to be deleted from enough storage
+servers, this deletes the file.
-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:
+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.
-http://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/historical/historical_known_issues.txt
+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
+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 <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1528>`_ for
+technical details.
-Issues in Tahoe-LAFS v1.8.0, released 2010-09-23
-================================================
Potential unauthorized access by JavaScript in unrelated files
--------------------------------------------------------------
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
+`<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>.
+at `<http://code.google.com/apis/safebrowsing/>`_ and
+`<http://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec>`_.
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 for Firefox in
-<https://bugzilla.mozilla.org/show_bug.cgi?id=368255>).
+your explicit consent, as described in `Firefox bugzilla ticket #368255
+<https://bugzilla.mozilla.org/show_bug.cgi?id=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
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
+`<http://lorrie.cranor.org/pubs/ndss-phish-tools-final.pdf>`_), and phishing
or malware attackers have learnt how to bypass them.
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.
Known issues in the FTP and SFTP frontends
------------------------------------------
-These are documented in docs/frontends/FTP-and-SFTP.txt and at
-<http://tahoe-lafs.org/trac/tahoe-lafs/wiki/SftpFrontend>.
+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>`_.
+
+
+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.
projects / tahoe-lafs / tahoe-lafs.git / blobdiff