-============
+
+See also cautions.rst_.
+
+.. _cautions.rst: file:cautions.rst
+
+============
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 .
+https://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
.. _the "historical known issues" document: historical/historical_known_issues.txt
-Issues in Tahoe-LAFS v1.8.2, released 2011-01-30
+Known Issues in Tahoe-LAFS v1.10, released 01-May-2013
+======================================================
- * `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`_
+ * `Unauthorized access by JavaScript in unrelated files`_
+ * `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`_
+ * `Privacy leak via Google Chart API link in map-update timing web page`_
----
-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:
-
-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*
-
-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
---------------------------------------------------------------
+Unauthorized access by JavaScript in unrelated files
+----------------------------------------------------
If you view a file stored in Tahoe-LAFS through a web user interface,
-JavaScript embedded in that file might be able to access other files or
-directories stored in Tahoe-LAFS which you view through the same web
-user interface. Such a script would be able to send the contents of
+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
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.
+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.
+
*how to manage it*
For future versions of Tahoe-LAFS, we are considering ways to close off
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
+.. _#615: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/615
----
-Potential disclosure of file through embedded hyperlinks or JavaScript in that file
------------------------------------------------------------------------------------
+Disclosure of file through embedded hyperlinks or JavaScript in that file
+-------------------------------------------------------------------------
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
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
+.. _#127: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/127
----
version of this file stated that Firefox had abandoned their phishing
filter; this was incorrect.
-.. _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
+.. _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
.. _Firefox bugzilla ticket #368255: https://bugzilla.mozilla.org/show_bug.cgi?id=368255
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
+.. _the SftpFrontend page: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/SftpFrontend
----
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.
+
+
+----
+
+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
+times in graphical form. The image is generated by constructing a URL for the
+`Google Chart API <https://developers.google.com/chart/image/>`_, which is
+then served by the `chart.apis.google.com` internet server.
+
+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
+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).
+
+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
+
+----
+
+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)
+
+
+.. _#1654: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1654
+
+----
+
+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:
+
+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*
+
+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: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1528
projects / tahoe-lafs / tahoe-lafs.git / blobdiff