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

New Issue

zooko · 2008-07-21T16:39:30Z

zooko commented

2008-07-21 16:39:30 +00:00

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>

zooko added the

labels 2008-07-21 16:39:30 +00:00

zooko self-assigned this 2008-07-21 16:39:30 +00:00

zooko commented

2008-07-21 17:24:01 +00:00

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

zooko commented

2008-07-30 21:05:59 +00:00

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>

zooko added the

fixed

label 2008-07-30 21:05:59 +00:00

zooko closed this issue

2008-07-30 21:05:59 +00:00

warner added this to the 1.3.0 milestone 2008-09-03 01:18:13 +00:00

zooko 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

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

http://hacktahoe.org