oss-security - Re: details about Tahoe-LAFS security problem #1654

server OS

Message-ID: <4F132C12.2050208@redhat.com>
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