Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 15 Jan 2012 12:42:10 -0700
From: Kurt Seifried <>
CC: "Zooko Wilcox-O'Hearn" <>
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 <>
> Date: Thu, Jan 12, 2012 at 4:35 PM
> Subject: [tahoe-dev] details about #1654 security problem
> To: Tahoe-LAFS development <>
> 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._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 ( 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
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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ