X-Git-Url: https://git.rkrishnan.org/?a=blobdiff_plain;f=docs%2Fknown_issues.rst;h=65610bc547090e775825677c884078d0db27ad93;hb=d7e71cd22b78f1dde0c69e7e09cf34987b8bc748;hp=db36315ea0e22effac96bdb40cc6c14f33c68e47;hpb=8c256de1f01abf66149134e7e35d2f79e8215b53;p=tahoe-lafs%2Ftahoe-lafs.git diff --git a/docs/known_issues.rst b/docs/known_issues.rst index db36315e..65610bc5 100644 --- a/docs/known_issues.rst +++ b/docs/known_issues.rst @@ -18,8 +18,8 @@ want to read `the "historical known issues" document`_. .. _the "historical known issues" document: historical/historical_known_issues.txt -Known Issues in Tahoe-LAFS v1.9.2, released 23-Jun-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`_ @@ -27,6 +27,7 @@ Known Issues in Tahoe-LAFS v1.9.2, released 23-Jun-2012 * `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`_ ---- @@ -252,6 +253,48 @@ 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 `_, 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 @@ -318,7 +361,7 @@ authorization (confidentiality), nor to change the contents of a file 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. @@ -347,17 +390,17 @@ 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 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