Date: Sun, 15 Jan 2012 12:42:10 -0700 From: Kurt Seifried <kseifried@...hat.com> To: oss-security@...ts.openwall.com CC: "Zooko Wilcox-O'Hearn" <zooko@...ko.com> Subject: Re: details about Tahoe-LAFS security problem #1654 On 01/12/2012 04:56 PM, Zooko Wilcox-O'Hearn wrote: > ---------- Forwarded message ---------- > From: Brian Warner <warner@...har.com> > Date: Thu, Jan 12, 2012 at 4:35 PM > Subject: [tahoe-dev] details about #1654 security problem > To: Tahoe-LAFS development <tahoe-dev@...oe-lafs.org> > > > 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 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. > > Bug #1654 (https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1654) was > created to track this problem, and is now closed. The same fix was > applied to trunk a few minutes ago, so trunk is now safe too. > > sorry! > -Brian > _______________________________________________ > tahoe-dev mailing list > tahoe-dev@...oe-lafs.org > http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev Apologies for the delay, please use CVE-2012-0051 for this issue. -- -- Kurt Seifried / Red Hat Security Response Team
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.