[tahoe-dev] report of an unsuccessful assault on our fortress

[Chris Palmer]

Zooko O'Whielacronx writes:

> Okay, your post deserves a thorough response and probably a few updates to
> our issue tracker, but it is way past my bed-time and I'm just going to
> fire off what comes to mind.

Fair enough; I did my bug-hunting in the same spirit. :)

> > Did you/he try to create a file that loads the main WUI page in an
> > iframe that takes up the whole browser viewport and then spies on the
> > contained iframe?
> 
> The effect of this would be that I send you a link (pointing to your local
> tahoe-lafs web gateway), you click on it, and then you see...  *something*
> of my choice -- a blank page, a file, the web gateway welcome page, or
> whatever, and then if you were to use that tab to navigate to a tahoe-lafs
> resource such as a confidential file, would my code gain access to that
> confidential file? I think it might depend on how I navigated to it. If
> the page was the web gateway welcome page and I pasted the cap to my file
> into it then I guess your JavaScript could gain access to that. But what
> if I paste a URL into the URL widget? Or click a bookmark?

The situation is, we are serving arbitrary HTML from potentially hostile
sources from our own origin (e.g. Alice saves Mallory's innocent-seeming
HTML page in her Tahoe-LAFS home directory). This is a classic web security
scary problem. When Alice later reads Mallory's document by browsing to it
in the WUI, Mallory's attack code runs in the WUI's origin. It can do things
like discover caps, et c. The only question is how. As your friend found,
you have to discover caps, you cannot guess them. The framing attack was one
thing I was able to think of after most of a glass of Macallan 18. Booze
affects me strongly, but I'm pretty sure it's a matter of attack payload
craftsmanship; the basic flaw is present and I have exploited it for clients
many times in the past. The unguessable caps make the attack payload trickier
than the usual trivial-pwnage payload, but not impossible.

> > ip-instead-of-hostname:different-port, et c.).
> 
> This would be a promising solution to our problem, if we could persuade
> the browser that every file loaded from the tahoe-lafs web gateway should
> be each its own separate origin. But practically speaking -- how? Listen
> on thousands of ports? We might run out of ports.

The simple answer is, have only 2 origins: WUI control, and data service.
All data is served from the same origin, and so all files are prone to each
other's depredations --- if bad files can discover the others' caps. But
hopefully they can't, since you have to be in the WUI control origin to
discover them.

This works well for Google, since they can use the google.com origin for
authenticated stuff and the IP address for anonymous cached documents. It
might or might not apply beautifully to your situation, but would be better
than the status quo. Therefore, you could consider the wildcard DNS option
that Brian mentioned (documentN.hostname, documentM.hostname, ...).

Note that you have to keep the cookie tied tightly to the WUI origin! If it
is broadly-scoped (*.hostname), you are back at Square One.

This means you need a secondary authentication mechanism, otherwise you'll
be serving documents to anonymous requesters via the document service
origin(s). The bloaty way is SAML; the clean way is short-lived, MAC'd
access token passed from origin to origin in the GET or POST requests. If
GET, then very short-lived authenticators are preferable (it's no good
having long-lived access tokens in discoverable places like URLs... but
you've heard me say that before ;) ). Symmetric, pre-shared signing key is
trivial since the origins are all hosted from the same machine, after all.

Alternately, you could depend on the unguessability of the caps to do your
access control for the document-service origins. That's basically what
you're already doing, so why not keep at it...

> > * The WUI is incredibly slow.
> 
> Hm, I wonder why. Here is a download that someone did around the time that
> you were messing with it:
> [...]
> 600 kilobytes per second seems respectable to me. Maybe this wasn't

It was a latency problem, not a throughput problem. I should have specified
that.

> Thanks for looking at this and polluting our public test directory with
> undeletable garbage!

Generating garbage is what I do. :)