update relnotes, rotate known_issues, for 1.9

[tahoe-lafs/tahoe-lafs.git] / docs / historical / historical_known_issues.txt

diff --git a/docs/historical/historical_known_issues.txt b/docs/historical/historical_known_issues.txt
index 88e1fccdf8b998add9288963e2d8c046623c7103..3756d6ce1609dd6f5adee3a5f96d01c089a28d8d 100644 (file)
--- a/docs/historical/historical_known_issues.txt
+++ b/docs/historical/historical_known_issues.txt
@@ -9,6 +9,88 @@ Issues in newer releases of Tahoe-LAFS can be found at:
 
 http://tahoe-lafs.org/source/tahoe/trunk/docs/known_issues.rst
 
+== issues in Tahoe 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
+
+
 
 == issues in Tahoe v1.1.0, released 2008-06-11 ==