+See also cautions.rst_.
+
+.. _cautions.rst: file:cautions.rst
+
============
Known Issues
============
.. _the "historical known issues" document: historical/historical_known_issues.txt
-Known Issues in Tahoe-LAFS v1.9.1, released 12-Jan-2012
-=======================================================
+Known Issues in Tahoe-LAFS v1.10, released 01-May-2013
+======================================================
* `Unauthorized access by JavaScript in unrelated files`_
* `Disclosure of file through embedded hyperlinks or JavaScript in that file`_
* `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`_
----
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
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
+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.
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 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.
+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
projects / tahoe-lafs / tahoe-lafs.git / blobdiff