[tahoe-dev] Tahoe-LAFS Weekly Call report 2012-08-29

[Zooko Wilcox-O'Hearn]

Folks:

Here is your traditional, once-a-week, cryptic, and potentially
inaccurate summary of the developer conference call. In what follows I
make no attempt to explain the context. Sorry -- don't have time right
now! However, we do try to explain contexts on tickets, so if this
sounds interesting to you, you can probably figure out what we're
talking about by reading #127, #615, #821, #827, #1455, #1797, and/or
#1798.

The ultimate goal is to allow you to view arbitrary content when
loaded from your Tahoe-LAFS gateway without allowing it to spy on or
interfere with other content also loaded from your Tahoe-LAFS gateway.
(And by "view" content I mean execute that content as a program.) This
is good to prevent exploits of "decentralized web apps" (such as my
blog: B9). Note that decentralized web apps hosted on Tahoe-LAFS are
_already_ pretty well-defended from one another. The unguessable URIs
go a long way to preventing a lot of attacks. This work is just about
closing off that one weird attack (which requires the user to navigate
*from* the prize content *to* the malicious content for it to work)
and also about providing Defense In Depth so that other unforeseen
attacks will be defeated before we even imagine them.

B9 https://lafsgateway.zooko.com/uri/URI:DIR2-RO:d73ap7mtjvv7y6qsmmwqwai4ii:tq5tqejzulg7yj4h7nxuurpiuuz5jsgvczmdamcalpk2rc6gmbsq/klog.html

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/127# Cap URLs leaked via
HTTP Referer header
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/615# Can JavaScript
loaded from Tahoe access all your content which is loaded from Tahoe?
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/821# A script in a file
viewed through the WUI can obtain the file's read cap
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/827# Put file download
links ('?save=true') in WUI directory listings
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1455# WUI: ambiently
accessible pages should framebust in order to prevent UI redressing
attacks
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1797# WUI: view content
in an HTML5 sandboxed iframe
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1798# Segregate gateway
HTTP ports: one for raw bytes and one for generated WUI pages


Tahoe-LAFS Developer Conference Call

2012-08-28

In attendance: Zooko, David-Sarah, Brian

scribe: Zooko

 defense against malicious javascript

Using html5 iframe sandboxing, each request to the gateway to load the
content of a cap "$CAP" actually returns a generated HTML page
containing a sandboxed iframe tag with src=SERVER:BYTESPORT/cap/$CAP.

b" Kaminsky back-jacking

b" an additional authority when the attacker knows the readcap, but we
want to prevent him from causing your browser to execute the contents
in certain context? / David-Sarah's weird idea of an extra key per
gateway

b" backward compatibility with scripts/apps that use the WAPI to load
raw bytes of caps?


What authority to I intend to extend to target content when I click on
its link in source content?

proposal: I intend for the target content to receive *no more
authority* when I click on its link than if I had typed in its URL.

Ways that this is not what the web currently does:

b" Click on a little question mark next to a field, it pops open a very
small explanation. If you go back to the original window and click the
question mark again, it will pop open the same explanation window
instead of a new one.

b" Generate a virtual history when everything is really /app#pageid


possible threat models:

Game 1: There is a secret prize cap, and you -- the attacker -- win if
any code of yours learns the secret cap. I will run your code, and
navigate around however you like, as a user. (The Kaminsky
back-jacking attack is a successful attack in this sort of game. It
requires that the user will navigate *from* the secret prize document
*to* attacker-controlled content.)

Game 2: There is a secret prize cap, and the user has it loaded *from
the barenakedcap port* in a window. Then the user navigates from that
content to an attacker-provided link. The link can, at the attacker's
discretion, point to attacker-controlled content stored in LAFS. So,
if the link goes to a barenakedcap containing attacker-controlled
content, then the Kaminsky back-jacking attack will work, letting that
attacker-controlled content gain access to the prize cap. But if the
link goes to an HTML5 sandbox wrappedcap, our use of HTML5 sandboxing
will prevent the resulting attacker-controlled content from gaining
the prize cap.


David-Sarah had an idea for a defense that might help in this Game 2
or in a related game, involving another encryption key which is known
to this gateway and unknown to the attacker. Brian argued that the
attacker-controlled content, that gets loaded in this gateway and
given access to that content, will eventually learn any such key or
any such transformation of the URL. Zooko proposed one-time barenaked
URLs -- when the gateway receives a request to load a wrappedcap, then
it generates an unguessable nonce, serves up the HTML5 sandbox wrapper
which includes <iframe src="$SERVER:$BARENAKEDDATAPORT/$NONCE">, and
over on the barenakeddata port, it will answer *only* the first
request for $NONCE by serving up the content. (Any subsequent requests
will get some kind of error.)


After the call was over, I, Zooko, began to wonder what's the point of
the barenakeddata port at all, and if the sandbox port could, instead
of including a src= link pointing to the one-time-URL on the
barenakeddata port,  instead include the actual content in the script
tag. I think Brian mentioned something like that on the call, about
having the gateway put all of the content into a data URL to put into
the script tag, or something. One possible motivation to have the
barenakeddata port at all is to support applications that need access
to the pristine, bitwise exact data, such as in order to download it
to disk. It is kind of funny that we want to have an HTTP server to
serve up pure data, but we never, never want a full-fledged HTTP
client (which interprets Javascript and HTML and all that) to look at
it! Full-fledged HTTP clients should only look at the other HTTP
server -- the one that serves up sandboxed content. Only custom
scripts should look at the one that serves up pure bytes.
_______________________________________________
tahoe-dev mailing list
tahoe-dev at tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE