escalation of authority from knowing a storage index to being able to delete corresponding shares

[zooko]

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.

[zooko@…]

In [5006/1.8.3]:

storage: remove the storage server's "remote_cancel_lease" function
We're removing this function because it is currently unused, because it is dangerous, and because the bug described in #1528 leaks the cancellation secret, which allows anyone who knows a file's storage index to abuse this function to delete shares of that file.
fixes #1528 (there are two patches that are each a sufficient fix to #1528 and this is one of them)

[zooko@…]

In [5007/1.8.3]:

immutable: prevent clients from reading past the end of share data, which would allow them to learn the cancellation secret
Declare explicitly that we prevent this problem in the server's version dict.
fixes #1528 (there are two patches that are each a sufficient fix to #1528 and this is one of them)

[david-sarah@…]

In [5013/1.8.3]:

interfaces: document that the 'fills-holes-with-zero-bytes' key should be used to detect whether a storage server has that behavior. refs #1528

[davidsarah]

Reassigning to me to apply the fix to trunk.