Written by Zooko Wilcox-O'Hearn, documenting ideas due to Nathan Wilcox, Brian Warner, and Zooko Wilcox-O'Hearn, 2008-07-18.
Nathan Wilcox is the -2nd winner of the Hack Tahoe-LAFS! contest. (He's the negative-second winner, because he won the contest before the contest was invented, and before Drew Perttula, the negative-first winner, did.)
In August of 2007, Tahoe-LAFS was in an early stage of development -- we were about to release Tahoe-LAFS, the Least-Authority Filesystem, v0.5. The v0.5 release was going to add a web API ("wapi") and a command-line interface ("cli") so that people could program their Tahoe-LAFS node without editing its Python source code. (See the Parade of Release Notes on the tahoe-lafs.org site.)
Nathan Wilcox contributed to the open source project by giving us a free security review -- he looked over the documentation and the design, and then he posted a note to the tahoe-dev list saying that the wui/wapi that we had designed was vulnerable to XSRF attacks. (This important, widespread class of attacks is nowadays known as "CSRF" instead of "XSRF".)
We thought about his attack for a while (leaving notes on this trac ticket), but we underestimated the severity of it and decided to go ahead and release Tahoe-LAFS v0.5 on Friday, August 17, 2007.
The very next post to the tahoe-dev list after the release announcement was from Nathan, and the Subject line was "Example XSRF attack.".. It contained a sample HTML file which had a hyperlink on it. If you clicked the hyperlink, it deleted a file out of your private Tahoe-LAFS directory! This was clearly a significant security problem, and we hastened to release Tahoe-LAFS v0.5.1 (on August 24) which fixed the problem.
How did we fix the problem? Well, the Tahoe-LAFS wapi/wui had been designed from the start with the capability access control paradigm -- each file or directory had a unique and unguessable URL, and knowledge of that URL was necessary and sufficient to grant access to that file or directory (as well as being the string used to identify that file or directory, just like any URL is). However, in addition to that capability-based scheme, we had also added a convenience feature, in which a special URL which began with the string "/vdrive/private" would be detected by the Tahoe-LAFS node and the capabilities to files and directories in the special "private" directory would be automatically supplied by the server even though they hadn't been supplied in the URL itself.
Some of the Tahoe-LAFS hackers had already objected that this special feature was inconsistent with the capability access control paradigm, but others of us had successfully argued that the convenience of being able to type a URL into your browser's location widget without having to type in a long unguessable string was worth it.
However, after Nathan's attack was posted we changed our minds, and so the major difference between Tahoe-LAFS v0.5 and v0.5.1 is that we simply removed the added feature of accessing a file or directory without using a capability to it. It turns out that we haven't missed it! Using URLs which contain full capabilities appears to be convenient enough.
We think this story may indicate a general principle that other people could learn from, and we've written up on this separate page:
solve CSRF attacks by making references unforgeable, not by making them unshareable
For alerting us to this important vulnerability, and for helping us to appreciate the severity of it, and for helping us to design a defense against it, Nathan Wilcox won the first ever "I Hacked Tahoe-LAFS!" t-shirt.
Here he is at the official awards ceremony at the office of AllMyData, June 26, 2008:
Nathan Wilcox being awarded with this "I Hacked Tahoe-LAFS!" t-shirt. (The t-shirt was present only as an image file at the awards ceremony, so it was projected onto a white board which was held in front of Nathan.)
Here's Nathan a few days after the awards ceremony, wearing the actual physical reification of his shirt:
(Also pictured: Nathan's brothers Josh Wilcox and Zooko Wilcox-O'Hearn.)