Changes between Version 5 and Version 6 of Ticket #1528


Ignore:
Timestamp:
2011-09-13T18:53:14Z (13 years ago)
Author:
davidsarah
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1528

    • Property Status changed from new to assigned

  • Ticket #1528 – Description

    v5 v6  
    1010
    11113. Fix some similar bounds violations in mutable files that could potentially lead to similar vulnerability. This vulnerability is probably not a concern in practice, because it doesn't arise unless the legitimate, authorized client deliberately writes a "hole" into the mutable file (by seeking past the end of the current data and not writing over all the bytes thus uncovered). No extant version of Tahoe-LAFS does this, so presumably no legitimate user would be exposed to that vulnerability.
     12
     13[source:1.8.3/docs/known_issues.rst#unauthorized-deletion-of-an-immutable-file-by-its-storage-index known_issues.rst for 1.8.3] has more details, but I'll paste the most relevant bit here:
     14
     15This vulnerability does not enable anyone to read file contents without authorization (confidentiality), nor to change the contents of a file (integrity).
     16
     17A person could learn the storage index of a file in several ways:
     18
     191. 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.
     20
     212. 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.
     22
     233. 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.
     24
     254. 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.