+
+
+----
+
+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