[tahoe-dev] Authority to DoS via WAPI

Brian Warner warner at lothar.com
Sat Jan 17 02:50:44 UTC 2009


[sorry about the formatting on this one.. I mistakenly sent my  
response directly to Toby instead of to the list.]

Toby said:
>> If Tahoe is "all about caps" then why does one of its primitive
>> operations ("PUT /uri") require no cap? This is the heart of my  
>> concern.

My response:
> Fair enough. I guess it's most accurate to say that we've split the  
> problem
> into two pieces: read/write access to a given directory or file, and
> read/write access to storage space in general. We've built a  
> capability
> system for the first piece, but have ambient authority for the second.
>
> The main use case I've been considering is one in which all  
> participants run
> their own nodes (listening on 127.0.0.1) so you never have to share  
> your caps
> with anyone else. In this use case, both your browser and your tahoe  
> node are
> agents working on your behalf, and nobody else's. So the capability
> discipline only needed to cover the world outside the browser+node  
> pair, i.e.
> on the wire between the node and the storage servers.
>
> One of the (incorrect) assumptions that this use case led me to make  
> was that
> nobody else can access your webapi node.. I forgot about browser  
> CSRF attacks
> in which someone else can cause your local browser to say things to  
> your
> local tahoe node (mostly POST.. they can do GET too but generally  
> they can't
> see the results, and browsers don't do PUT or DELETE at all). One of  
> the
> holes was that the node used to hold a root dircap for you, and you  
> could hit
> the webapi with /private/foo.txt to access a file in that dircap,  
> and a CSRF
> attack could delete/rename/upload/replace files in that dircap. We  
> closed
> some of the holes that were caused by my assumption (the ones that  
> fall into
> the "first piece" above) by moving the capability-discipline  
> boundary further
> out (by removing /private and not giving the webapi ambient  
> authority over
> any existing files or directories). This prevents the CSRF attacker  
> from
> affecting any of the user's files or directories. The lesson learned  
> is that
> if the node doesn't have any secrets stored in a file somewhere,  
> then users
> have to supply that secret themselves.
>
> But we did not move that boundary to cover the second piece  
> (creating new
> files and directories), because we realized it was a bigger question  
> than we
> were prepared to address back then. The remaining hole allows a CSRF  
> attacker
> to waste space: they can cause data to be uploaded or new empty  
> directories
> to be created, but they can't see the new caps that result, so it  
> can't
> benefit them, even if it hurts you.
>
> The remove-"/private" fix was a partial way to address the fact  
> that, while
> your node may be working entirely for you (and listening on an  
> interface
> which is safe from outside access), your own browser may be a  
> hostile agent,
> working for others. If we extend this thinking, and decide that we  
> should
> assume the node is fully exposed to the outside world (anybody can  
> hit the
> webapi port, POST/GET/PUT/DELETE/etc), then it makes it more clear  
> that we're
> providing ambient upload authority.
>
> The vague idea was that groups who want to run a grid and make sure  
> that
> nobody else can cause space to be consumed on it should keep the  
> grid closed:
> don't give out the introducer.furl, to keep control over which nodes  
> get to
> connect to the storage servers. They must also keep control over  
> their nodes,
> by preventing CSRF attacks. But creating new unlinked files and  
> directories
> is a common operation (I do POST /uri?t=mkdir all the time, to create
> throwaway directories to share a file with zooko), so whatever tools  
> they use
> to prevent these annoyance/DoS CSRF attacks must still allow  
> creation of
> unlinked files and directories. There's no obvious filecap/dircap  
> authority
> for these operations, so we'd have to create a new one. But what? An
> unguessable string, stored in the node somewhere, that must be  
> pasted into
> the upload/mkdir-unlinked form? It wasn't clear how to make that  
> useable..
> bookmarks work pretty well for dircaps, but a secret that's  
> orthogonal to the
> filesystem hierarchy wouldn't fit very well there.
>
> So, we didn't know how to correctly and usefully address the  
> problem. Rather
> than implement a quick binary authority model for storage space  
> consumption,
> we've (slowly) been designing an Accounting scheme that will give us
> finer-grained control over it. It's still going to have to traverse  
> the
> webapi, and there will be some unguessable string (probably a signed
> certificate) that must be passed along with space-consuming webapi
> operations, and part of the design challenge is finding a human- 
> useable way
> to implement that.
>
> It would be easier if we could consider the node to be running  
> entirely on
> behalf of a single user, which may indeed be the case for your  
> personal node.
> But we've also got to handle the allmydata.com case, in which we have
> hundreds of web-only users talking to a shared node (run by us)  
> which needs
> to utilize Alice's or Bob's storage-authority as appropriate.
>
> Anyways, that was a very long-winded way to answer your question:
>
>> If Tahoe is "all about caps" then why does one of its primitive
>> operations ("PUT /uri") require no cap? This is the heart of my  
>> concern.
>
> with a cop-out: I didn't feel that nuisance posed by a CSRF attacker  
> was
> worth making it difficult to upload unlinked files or create new  
> unlinked
> directories. The CSRF attacker is limited to POST, with form data  
> that was
> downloaded in the attacking page, so all they can do is upload small  
> files
> and create empty directories. They get to do one of these operations  
> per
> browser page load, and they can't get the filecaps/dircaps thus  
> created, so
> the worst they can do is consume space at some fairly slow rate. Oh  
> well.
>
>
> ok, back to GC and Accounting work.. :)
>
> cheers,
> -Brian
>
>
>
>



More information about the tahoe-dev mailing list