[tahoe-lafs-trac-stream] [tahoe-lafs] #1654: placeholder

[tahoe-lafs]

#1654: placeholder
-------------------------------+-------------------------------
     Reporter:  warner         |      Owner:  nobody
         Type:  defect         |     Status:  closed
     Priority:  supercritical  |  Milestone:  1.9.1
    Component:  code-mutable   |    Version:  1.9.0
   Resolution:  fixed          |   Keywords:  integrity mutable
Launchpad Bug:                 |
-------------------------------+-------------------------------

Comment (by warner):

 Dear Tahoe-LAFS Users:

 On 08-Jan-2012, Tahoe-LAFS core member Kevan Carstensen (author of the
 MDMF code) discovered a serious bug in v1.9.0 (the current stable
 release) that allows attackers to corrupt downloads of mutable files in
 certain cases. We've released Tahoe-LAFS v1.9.1 which removes this
 vulnerability. All users are encouraged to upgrade immediately to
 v1.9.1, or to downgrade to v1.8.3.

 v1.9.0 was released about two months ago. As far as we know, ArchLinux
 is the only distribution to have packaged v1.9.0 (the others are still
 on v1.8.3, which is safe). So if you get your Tahoe-LAFS through a
 non-ArchLinux package, you're probably fine. If you build it yourself,
 you should upgrade.

 In Tahoe, files are encrypted, and then encoded into multiple redundant
 shares. Integrity-checking information (Merkle hash trees) are included
 in the shares to detect corruption. When downloading, these hashes are
 checked before combining the shares in the decoder, which generates
 ciphertext that can be decrypted into the original file. Mutable files
 have two sets of hash trees, the "share hash tree" (which covers all
 shares), and the "block hash trees" (which sit under the share-hash-tree
 and cover the individual blocks that make up each share, one block per
 128KiB segment of the original file).

 The new mutable downloader released in v1.9.0, which supports both the
 old-style SDMF format and the new MDMF format, has a bug in which the
 share-hash-tree check is accidentaly bypassed when the Merkle hash tree
 is already fully populated. This doesn't normally occur, but shares can
 contain additional hash-tree nodes beyond the ones they strictly need.
 An attacker could modify one share to include the entire tree, then
 change the block data in the remaining shares. They would need to update
 the block-hash-trees in those doctored shares, but because of the bug,
 these tree roots will not be compared against the share hash tree.

 The attacker is thus able to control the input to the ZFEC decoder for
 all but the first share received (which must have valid block data).
 This gives them the ability to flip bits of the plaintext without
 triggering the CorruptShareError exceptions that share corruption would
 normally produce, causing corrupted plaintext to be delivered to an
 unwitting client.

 To exploit this bug, the attacker must be able to deliver multiple
 modified shares to your client, in a particular order: this means they
 must control one or more of your storage servers.

 Note that this does not directly reveal the plaintext to the attacker
 (this is an integrity failure, not a confidentiality failure). However,
 "encryption without authentication" is never a safe state of affairs,
 and can frequently be exploited to reveal information about the
 plaintext (perhaps by inducing observable failures by flipping bits in
 messages of a known format). In addition, clients which read corrupted
 data as part of a read-modify-write operation (such as directory
 modifications) may then write the corrupted data back out to the file,
 making the corruption persist even after the client has been fixed.

 v1.9.1 fixes this by removing the accidental "if" clause, making the
 share-hash-tree check unconditional.

 The specific bug is in source:src/allmydata/mutable/retrieve.py,
 Retrieve._validate_block, around the call to
 share_hash_tree.set_hashes(), and was introduced in git revisionid
 [ac3b2647dd2c45cd1ddbf5b130ee5a780c66c73b] with the MDMF-capable
 downloader rewrite around 01-Aug-2011. The bug was first present in
 shipping code in Tahoe-LAFS-1.9.0, on 30-Oct-2011. It was fixed in
 commit [9b4b03a474a2c9050c8347459ab6698839be7288], shipped in
 Tahoe-LAFS-1.9.1 on 12-Jan-2012. We are continuing to audit the 1.9.x
 mutable downloader code to search for other potential bugs.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1654#comment:7>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage