[tahoe-dev] CRISP Advisory 2008-01

[zooko]

On Jul 21, 2008, at 0:39 AM, Christian Grothoff wrote:

>  It is possible for a user to create a URI on Tahoe
>  that corresponds to two different files (but URIs
>  are supposed to be unique). As a result,
>  an adversary might be able to publish a benign file
>  and malware under the same URI, make initially the
>  benign file available to users causing the URI to be
>  shared and then switch the benign file for malware
>  (without changing the URI).
...
>  Tahoe uses 3-out-of-10 ECC in its file encoding.
>  The most simplistic form of the attack simply
>  uses (for the URI) 5 shares of the benign file
>  and 5 shares of the malicious file to construct
>  the URI. The check that the content matches a
>  hash code that is part of the URI is easily
>  bypassed since doing this check happens at the
>  discression of the publisher.

Thank you, Christian!

I've updated http://hacktahoe.org to include your discovery in the  
"News" section.

It is easy to fix this issue, because we already have another  
integrity check -- a Merkle Tree over the ciphertext -- which nails  
down one exact ciphertext for one read-cap or verify-cap (terminology  
note: we tend to use "cap" nowadays to mean the string which we used  
to call a "URI").  That integrity check was made optional in Tahoe  
v1.0 -- downloaders didn't require it but would check it if it was  
present, and uploaders still produced it.  (So, therefore, your  
advisory page [1] would be more accurate if it said that Tahoe 1.0  
and Tahoe 1.1 were vulnerable.)

Therefore it was very easy to fix this -- we just made downloaders  
require that hash value and refuse to accept a file that doesn't have  
it.  Here's the patch:

http://allmydata.org/trac/tahoe/changeset/2777

Here is the trac ticket to track this issue:

http://allmydata.org/trac/tahoe/ticket/491

We also added a unit test to make sure that if the download code  
encounters a file without the ciphertext Merkle Tree hash then it  
raises an integrity check exception.

If only all bugs were this easy to fix!

Thanks again, Christian, for finding this flaw in the immutable file  
integrity check mechanism!

Regards,

Zooko

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