[cap-talk] Google Chrome Interview

Bill Frantz frantz at pwpconsult.com
Mon Apr 20 19:49:10 EDT 2009


cap-talk at collinjackson.com (Collin Jackson) on Sunday, April 19, 2009 wrote:

>File upload is described in a little more detail in our 2008 technical
>report: <http://crypto.stanford.edu/websec/chromium/>
>
>"Users can upload files to web sites using the file upload control. When
>the user clicks the form control, the browser displays a file picker
>dialog that lets the user select a file to upload. If the browser
>kernel did not restrict which files the rendering engine could upload,
>an attacker who compromised the rendering engine could read an
>arbitrary file on the user’s file system by uploading the file to
>attacker.com. Instead of confirming each file upload with a dialog box,
>Chromium uses a design similar to the DarpaBrowser’s “powerbox”
>pattern [27], treating the user’s selection of a file with a file picker
>dialog as an authorization to upload the file to an arbitrary web site.
>The browser kernel is responsible for displaying the file picker dialog
>and records which files the user has authorized for which instances of
>the rendering engine..."

This design is really a step forward.

The big problem with these designs, as I see it, is having a confined
environment where you can enforce some security properties. The Polaris
project had to stand on its head to find such an environment in Windows,
and finally settled on running the confined program under a different,
specially created, user account.

Fortunately in CapROS, we have such an environment. We are able to use that
environment to protect against buffer overruns in our web server. Quoting
a portion of the description in
<http://sourceforge.net/mailarchive/message.php?msg_name=r02010500-1049-
E9FCEA08FFA811DD95A30030658F0F64%40%5B192.168.1.5%5D>:

>If we assume we create a new instance of the http object for each new tcp
>connection, and that the code of these instances is isolated from each
>other (i.e. taking over one instance doesn't allow taking over other
>instances), then the only Swiss numbers an instance knows are those passed
>in over the connection, and those it can find using its authorities.
>
>If we keep the Swiss number to object mapping in a directory which can not
>be enumerated (in an iterator, or getNext() kind of function), then our
>0wned http instance can only guess Swiss numbers and ask the directory if
>it guessed right.

For the whole discussion thread, see <http://sourceforge.net/mailarchive/message.php?msg_id=499C9E8D.6030708%40macslab.com>

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | Airline peanut bag: "Produced  | Periwinkle
(408)356-8506      | in a facility that processes   | 16345 Englewood Ave
www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos, CA 95032


More information about the cap-talk mailing list