Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 14 Sep 2011 07:20:20 -0600
From: "Zooko O'Whielacronx" <zooko@...ko.com>
To: oss-security@...ts.openwall.com
Subject: unauthorized deletion of file in Tahoe-LAFS

Dear People of the oss-security list:

The Tahoe-LAFS core team has discovered a bug in Tahoe-LAFS v1.8.2
(the current stable release) and all earlier versions starting with
Tahoe-LAFS v1.3.0 that could allow users to unauthorizedly delete
immutable files in some cases. We've released Tahoe-LAFS v1.8.3 which
closes this vulnerability.

In Tahoe-LAFS, each file is encoded into a redundant set of "shares"
(like in RAID-5 or RAID-6), and each share is stored on a different
server. There is a secret string called the "cancellation secret"
which is stored on the server by being appended to the end of the
share data. The bug is that the server allows a client to read past
the end of the share data and thus learn the cancellation secret. A
client which knows the cancellation secret can use it to cause that
server to delete the shares it stores of that file.

Tahoe-LAFS v1.8.3 includes a set of patches (attached) which do three things:

1. Fix the bounds violation in reading of immutable files which
allowed the clients to learn the cancellation secrets.

2. Remove the function which takes a cancellation secret and deletes
shares. This function (named "remote_cancel_lease") was not actually
used, as all users currently rely on a different mechanism for
deleting unused data (a garbage collection mechanism in which unused
shares get deleted by the server once no client has renewed its lease
on them in more than a month).

3. Fix some similar bounds violations in mutable files that could
potentially lead to similar vulnerability. This vulnerability is
probably not a concern in practice, because it doesn't arise unless
the legitimate, authorized client deliberately writes a "hole" into
the mutable file (by seeking past the end of the current data and not
writing over all the bytes thus uncovered). No extant version of
Tahoe-LAFS does this, so presumably no legitimate user would be
exposed to that vulnerability.



ANNOUNCING Tahoe, the Least-Authority File System, v1.8.3

The Tahoe-LAFS team announces the immediate availability of version 1.8.3 of
Tahoe-LAFS, an extremely reliable distributed storage system. Get it here:

http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/quickstart.rst

Tahoe-LAFS is the first distributed storage system to offer
"provider-independent security" — meaning that not even the
operators of your storage servers can read or alter your data
without your consent. Here is the one-page explanation of its
unique security and fault-tolerance properties:

http://tahoe-lafs.org/source/tahoe/trunk/docs/about.html

The previous stable release of Tahoe-LAFS was v1.8.2, which was
released January 30, 2011 [1].

v1.8.3 is a stable bugfix release which fixes a security issue. See the file
[2] and known_issues.rst [3] file for details.


WHAT IS IT GOOD FOR?

With Tahoe-LAFS, you distribute your filesystem across
multiple servers, and even if some of the servers fail or are
taken over by an attacker, the entire filesystem continues to
work correctly, and continues to preserve your privacy and
security. You can easily share specific files and directories
with other people.

In addition to the core storage system itself, volunteers
have built other projects on top of Tahoe-LAFS and have
integrated Tahoe-LAFS with existing systems, including
Windows, JavaScript, iPhone, Android, Hadoop, Flume, Django,
Puppet, bzr, mercurial, perforce, duplicity, TiddlyWiki, and
more. See the Related Projects page on the wiki [4].

We believe that strong cryptography, Free and Open Source
Software, erasure coding, and principled engineering practices
make Tahoe-LAFS safer than RAID, removable drive, tape,
on-line backup or cloud storage.

This software is developed under test-driven development, and
there are no known bugs or security flaws which would
compromise confidentiality or data integrity under recommended
use. (For all important issues that we are currently aware of
please see the known_issues.rst file [3].)


COMPATIBILITY

This release is compatible with the version 1 series of
Tahoe-LAFS. Clients from this release can write files and
directories in the format used by clients of all versions back
to v1.0 (which was released March 25, 2008). Clients from this
release can read files and directories produced by clients of
all versions since v1.0. Servers from this release can serve
clients of all versions back to v1.0 and clients from this
release can use servers of all versions back to v1.0.

This is the fourteenth release in the version 1 series. This
series of Tahoe-LAFS will be actively supported and maintained
for the forseeable future, and future versions of Tahoe-LAFS
will retain the ability to read and write files compatible
with this series.


LICENCE

You may use this package under the GNU General Public License,
version 2 or, at your option, any later version. See the file
"COPYING.GPL" [5] for the terms of the GNU General Public
License, version 2.

You may use this package under the Transitive Grace Period
Public Licence, version 1 or, at your option, any later
version. (The Transitive Grace Period Public Licence has
requirements similar to the GPL except that it allows you to
delay for up to twelve months after you redistribute a derived
work before releasing the source code of your derived work.)
See the file "COPYING.TGPPL.html" [6] for the terms of the
Transitive Grace Period Public Licence, version 1.

(You may choose to use this package under the terms of either
licence, at your option.)


INSTALLATION

Tahoe-LAFS works on Linux, Mac OS X, Windows, Cygwin, Solaris,
*BSD, and probably most other systems. Start with
"docs/quickstart.html" [7].


HACKING AND COMMUNITY

Please join us on the mailing list [8]. Patches are gratefully
accepted -- the RoadMap page [9] shows the next improvements
that we plan to make and CREDITS [10] lists the names of people
who've contributed to the project. The Dev page [11] contains
resources for hackers.


SPONSORSHIP

Atlas Networks has contributed several hosted servers for performance
testing. Thank you to Atlas Networks for their generous and public-spirited
support.


HACK TAHOE-LAFS!

If you can find a security flaw in Tahoe-LAFS which is serious
enough that we feel compelled to warn our users and issue a fix,
then we will award you with a customized t-shirts with your
exploit printed on it and add you to the "Hack Tahoe-LAFS Hall
Of Fame" [12].


ACKNOWLEDGEMENTS

This is the eighth release of Tahoe-LAFS to be created solely
as a labor of love by volunteers. Thank you very much to the
team of "hackers in the public interest" who make Tahoe-LAFS
possible.

Zooko Wilcox-O'Hearn
on behalf of the Tahoe-LAFS team

September 13, 2011
Boulder, Colorado, USA


[1] http://tahoe-lafs.org/trac/tahoe/browser/relnotes.txt?rev=5164
[2] http://tahoe-lafs.org/trac/tahoe-lafs/browser/1.8.3/NEWS?rev=5014
[3] http://tahoe-lafs.org/trac/tahoe/browser/docs/known_issues.rst
[4] http://tahoe-lafs.org/trac/tahoe/wiki/RelatedProjects
[5] http://tahoe-lafs.org/trac/tahoe/browser/COPYING.GPL
[6] http://tahoe-lafs.org/source/tahoe/trunk/COPYING.TGPPL.html
[7] http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html
[8] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
[9] http://tahoe-lafs.org/trac/tahoe/roadmap
[10] http://tahoe-lafs.org/trac/tahoe-lafs/browser/1.8.3/CREDITS?rev=5003
[11] http://tahoe-lafs.org/trac/tahoe/wiki/Dev
[12] http://tahoe-lafs.org/hacktahoelafs/

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.