URIs do not refer to unique files in Allmydata Tahoe #491

Closed
opened 2008-07-21 16:39:30 +00:00 by zooko · 4 comments
zooko commented 2008-07-21 16:39:30 +00:00
Owner

As Christian Grothoff observed, it is possible for an uploader to make some shares produce one file, and other shares produce another file. The integrity check that is currently required -- the Merkle Tree over the shares -- ensures that only one set of shares can be used for a given read-cap or verify-cap, but it doesn't ensure that only one file can be produced.

The intended semantics of Tahoe immutable files are that there is only one file that can be denoted by a given read-cap or write-cap, so this is a bug. It isn't a major security issue for the typical current use case, since only the original uploader can construct a file to have this ambiguity -- this cannot be used to attack the integrity of a file if you are not the original uploader of that file. However, it isn't the property that we want and it could be used for mischief, so we're going to fix it.

Christian's advisory:

http://crisp.cs.du.edu/?q=node/88

His post to tahoe-dev:

http://allmydata.org/pipermail/tahoe-dev/2008-July/000689.html

As Christian Grothoff observed, it is possible for an uploader to make some shares produce one file, and other shares produce another file. The integrity check that is currently required -- the Merkle Tree over the shares -- ensures that only one set of shares can be used for a given read-cap or verify-cap, but it doesn't ensure that only one file can be produced. The intended semantics of Tahoe immutable files are that there is only one file that can be denoted by a given read-cap or write-cap, so this is a bug. It isn't a major security issue for the typical current use case, since only the original uploader can construct a file to have this ambiguity -- this cannot be used to attack the integrity of a file if you are not the original uploader of that file. However, it isn't the property that we want and it could be used for mischief, so we're going to fix it. Christian's advisory: <http://crisp.cs.du.edu/?q=node/88> His post to tahoe-dev: <http://allmydata.org/pipermail/tahoe-dev/2008-July/000689.html>
tahoe-lafs added the
code-encoding
major
defect
1.1.0
labels 2008-07-21 16:39:30 +00:00
zooko commented 2008-07-21 17:24:01 +00:00
Author
Owner

I updated source:docs/known_issues.txt to describe this issue.

I updated source:docs/known_issues.txt to describe this issue.
zooko commented 2008-07-30 21:05:59 +00:00
Author
Owner

This was fixed by changeset:9461887e0a98274e and released in Tahoe 1.2.0. The known_issues.txt describes it, r2788, line 37 ("issue 9"):

http://allmydata.org/trac/tahoe/browser/docs/known_issues.txt?rev=5b84721c7ec215e8#L37

This was fixed by changeset:9461887e0a98274e and released in Tahoe 1.2.0. The known_issues.txt describes it, r2788, line 37 ("issue 9"): <http://allmydata.org/trac/tahoe/browser/docs/known_issues.txt?rev=5b84721c7ec215e8#L37>
tahoe-lafs added the
fixed
label 2008-07-30 21:05:59 +00:00
zooko closed this issue 2008-07-30 21:05:59 +00:00
tahoe-lafs added this to the 1.3.0 milestone 2008-09-03 01:18:13 +00:00
tahoe-lafs modified the milestone from 1.3.0 to 1.2.0 2008-09-03 16:39:14 +00:00
zooko commented 2009-12-15 17:59:30 +00:00
Author
Owner

Christian Grothoff won a place on the I Hacked Tahoe! Hall of Fame for this:

http://hacktahoe.org

Christian Grothoff won a place on the I Hacked Tahoe! Hall of Fame for this: <http://hacktahoe.org>
davidsarah commented 2009-12-16 00:35:55 +00:00
Author
Owner

For historical reference, the URL of Christian's original advisory should have been http://crisp.cs.du.edu/?q=node/90

For historical reference, the URL of Christian's original advisory should have been <http://crisp.cs.du.edu/?q=node/90>
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#491
No description provided.