[tahoe-lafs-trac-stream] [tahoe-lafs] #1528: escalation of authority from knowing a storage index to being able to delete corresponding shares

[tahoe-lafs]

#1528: escalation of authority from knowing a storage index to being able to
delete corresponding shares
-------------------------+-------------------------------------------------
     Reporter:  zooko    |      Owner:  davidsarah
         Type:  defect   |     Status:  assigned
     Priority:           |  Milestone:  1.8.3
  critical               |    Version:  1.9.0a1
    Component:  code-    |   Keywords:  security preservation anti-
  storage                |  censorship storage leases
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Changes (by davidsarah):

 * status:  new => assigned


Old description:

> The Tahoe-LAFS core team has discovered a bug in Tahoe-LAFS v1.8.2 and
> all earlier versions starting with Tahoe-LAFS v1.3.0 that could allow
> users to unauthorizedly delete immutable files in some cases.
>
> In Tahoe-LAFS, each file is encoded into a redundant set of "shares"
> (like in RAID-5 or RAID-6), and each share is stored on a different
> server. There is a secret string called the "cancellation secret" which
> is stored on the server by being appended to the end of the share data.
> The bug is that the server allows a client to read past the end of the
> share data and thus learn the cancellation secret. A client that knows
> the cancellation secret can use it to cause that server to delete the
> shares it stores of that file.
>
> We have prepared a set of patches that do three things:
>
> 1. Fix the bounds violation in reading of immutable files that allowed
> the clients to learn the cancellation secrets.
>
> 2. Remove the function that takes a cancellation secret and deletes
> shares. This function (named "remote_cancel_lease") was not actually
> used, as all users currently rely on a different mechanism for deleting
> unused data (a garbage collection mechanism in which unused shares get
> deleted by the server once no client has renewed its lease on them in
> more than a month).
>
> 3. 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.

New description:

 The Tahoe-LAFS core team has discovered a bug in Tahoe-LAFS v1.8.2 and all
 earlier versions starting with Tahoe-LAFS v1.3.0 that could allow users to
 unauthorizedly delete immutable files in some cases.

 In Tahoe-LAFS, each file is encoded into a redundant set of "shares" (like
 in RAID-5 or RAID-6), and each share is stored on a different server.
 There is a secret string called the "cancellation secret" which is stored
 on the server by being appended to the end of the share data. The bug is
 that the server allows a client to read past the end of the share data and
 thus learn the cancellation secret. A client that knows the cancellation
 secret can use it to cause that server to delete the shares it stores of
 that file.

 We have prepared a set of patches that do three things:

 1. Fix the bounds violation in reading of immutable files that allowed the
 clients to learn the cancellation secrets.

 2. Remove the function that takes a cancellation secret and deletes
 shares. This function (named "remote_cancel_lease") was not actually used,
 as all users currently rely on a different mechanism for deleting unused
 data (a garbage collection mechanism in which unused shares get deleted by
 the server once no client has renewed its lease on them in more than a
 month).

 3. 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.

 [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:

 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.

--

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1528#comment:6>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage