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

Brian Warner warner at lothar.com
Mon Jul 26 23:03:44 UTC 2010


> The unguessable caps make the attack payload trickier than the usual
> trivial-pwnage payload, but not impossible.

Yeah, it means that the attacker cannot acquire authority (the ability
to read or write a tahoe file) by merely guessing at a URL: they have to
steal one from a tab which already knows it (either because it was
downloaded from a tahoe file, or because it is a directory listing with
lots of tahoe files in it). Stealing things from tabs means scripting
tabs (looking inside their JS state), which means the domain hosting the
attacker's JS must be the same as (or at least related to) the domain
hosting the victim tab.

> 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.

I've heard that tabs are enumerable: the most likely attack vector I
know of right now is:

 * upload your attack JS in a tahoe file
 * give Alice the filecap, convince her to view it in a browser
 * your attack JS looks for all other tabs coming from the same origin
   (i.e. other pages Alice is reading through her tahoe client)
 * your attack injects a script into the victim tab, learns its filecap,
   and phones home (sets an IMG tag to a URL under your control with the
   filecap as a queryarg)

The attack is most damaging if it finds a directory listing, since then
it gets more than just a single filecap. The clever attack will open up
a new tab (or small unobtrusive window) and poll for tabs every couple
of seconds, to capture any document that Alice happens to look at while
the attack remains open.

(I'm looking for documentation about the "enumerable tabs" stuff now..
so far I've only found a reference[1] to window.open('',NAME) which can
find "named" windows, but not the usual unnamed ones).

The next most likely attack I can think of is the error message you
pointed out: give Alice a URL that points to her tahoe node but contains
a weird pathname component that contains a <script> tag: when Tahoe
can't find that child, it displays an error message to that effect,
giving the attacker control over a page which has been delivered by the
right origin, now look for other tabs to attack.

> 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.

Note: tahoe does not use cookies. All the authority is contained in the
URL, none is contained in ambient places like cookies. (when we get to
Accounting, we're going to try hard to retain this property, which will
probably mean passing access tokens from one request to the next, as you
suggested).

thanks for digging into this!
 -Brian


[1]: http://code.google.com/p/browsersec/wiki/Part2 : "Gaps in DOM
     access control"



More information about the tahoe-dev mailing list