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 <[email protected]> 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 [email protected] < /etc/hosts". Note the double HTML > entity-encoding, "&lt;": > > <td><a > href="../../uri/URI%3ADIR2%3Axs7uulujbkwwvs6pqldzs4wgsm%3A4jt6jhxa3ryjdtjuq2esxw6pibcq2pzgovkk3nbjnvix2w5tepda/">zumby-bumby > ; mail [email protected] &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 _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
