Re: Electrolysis security

On Aug 18, 2009, at 12:35, Benjamin Smedberg <[email protected]>  
wrote:

> On 8/17/09 5:03 PM, Lucas Adamski wrote:
>
>> I wonder if there's a way for us to eventually verify that there  
>> aren't
>> direct network calls happening from content processes.  I'm concerned
>> about some hacks or special-casing that might have been implemented  
>> ages
>> ago then forgotten about (such as 307 redirects being a separate code
>> path from other redirects).
>
> The eventual security sandbox would prevent the network access in  
> any case.
>
> It's certainly possible for us to say that certain functions may not  
> be
> called from a content process and enforce that with runtime aborts,  
> at the
> cost of a runtime check, but I can't imagine that the runtime check  
> would be
> a problem at least in this case... we don't open sockets in tight  
> loops.

Sounds good to me thought it should be noted there are currently  
limitations on certainly platforms (2000 and XP, and < OX 10.5)  
regarding the ability to restrict network access.  So once we get to  
the security-specific phase of the project we might have to face some  
hard trade-offs.  See:
http://dev.chromium.org/developers/design-documents/sandbox#TOC-The-token
http://dev.chromium.org/developers/design-documents/sandbox/osx-sandboxing-design

>
>> Regarding file access, could you elaborate a bit on what you mean by
>> "only grants access to files"?   Ideally the file download process  
>> from
>> the dialog-onwards is a parent-only process that does not involve the
>> content process at all (other than simple progress updates).  I just
>
> I'm mainly concerned with file uploads. With <input type="file"> you  
> give
> the website access to the file data (scriptably even). The model  
> Chromium
> uses is similar to this:
>
> content process: fires event when the <input type="file"> browse  
> button is
> clicked
> chrome process: sees event, pops up file picker (perhaps with an  
> unspoofable
> "Select a file to upload to www.example.com dialog text/header)
> chrome process: after file is selected, open a file descriptor to  
> the file
> and hand it back to the content process, thereby giving the content  
> process
> access to the file.
>

Doesn't the model above require file access privileges for the content  
process?  It seems like a restricted process shouldn't be able to  
write to the FS even with a valid handle as that would seem to imply  
low-level access to the underlying FS.  At minimum it seems to invite  
escalation of privilege attacks.  A better model might be for the  
broker process to handle the file I/O on behalf of the content process  
using a randomly generated file reference that is not an underlying  
file descriptor; something strongly coupled to that particular content  
process (to prevent rogue processes from trying to brute force other  
file references).

> File downloads seem easy to control: the content process either  
> forwards a
> download request or actual data to the chrome process, which handles  
> the
> data, saving to disk or to a helper application as appropriate.
>
>> I'm not proposing changing the interaction model but just wondering  
>> if
>> its possible to prevent content processes from throwing native- 
>> looking
>> dialogs?  For that matter, how much can we restrict content process
>> control over the screen.  Could a content process convincingly fake a
>> Vista UAC, for example (efficacy of that mechanism aside :) )?
>
> In the security sandbox model the content process has no access to the
> screen at all... it only draws to sharedmemory buffers which are then
> painted by the chrome process into the browser content area.
>
> All dialogs would be brokered through the chrome process, although  
> that
> doesn't necessarily prevent spoofing...

Hmm.  Yes, chrome processes should ideally provide the "window  
dressing" to help identify valid dialogs from spoofed ones, but in the  
end I don't know there's much we can do to prevent dialog spoofing in  
the content pane, short of moving them out of the content space  
entirely (which I still think is a good idea but not your problem :).

>
>> It should address it insofar we are conscious of what threats we  
>> intend
>> to address, and which ones we do not.  So long as we can be explicit
>> about which threats we will not be trying to mitigate via (later  
>> phases
>> of) electrolysis.  Given electrolysis touches virtually every part of
>> the browser, I'm not sure its threat model is severable from the  
>> wider
>> browser security model.
>
> So, what do you propose from here? For example, I don't think we  
> should try
> to use the multi-process architecture to isolate password/cookie  
> data across
> origins. Should it be removed from that list, or explicitly marked as
> not-a-goal, or just proposed here for further discussion?

Most of these threats are still worthy of future discussion I think,  
because it would be great if we could actually figure out some way of  
(at least partially) mitigating password and session management  
threats, for example.   In particular we might be able to do something  
for HTTPOnly cookies, since they are not accessible from JS there  
really may not be any reason to hand them to a content process if we  
can avoid it.  There are definitely established best practices around  
moving sensitive session info into HTTPOnly cookies to mitigate XSS  
attacks.  http://www.owasp.org/index.php/HTTPOnly

Not sure what we could do regarding password manager, though... if we  
could at least restrict content's ability to pull out arbitrary  
passwords, but I can't think of anything ATM.  Then again, maybe with  
the recent clickjacking issues perhaps an argument could be made that  
a well constructed login page should refuse to load if the origin of  
the request is untrustworthy, but that seems like a stretch.. even to  
me. :)

I don't think we should remove threats unless they become invalid for  
some reason (seems unlikely), but in the end we'll just document which  
ones we are not intending to mitigate in electrolysis and a short  
rationale for why not.  On my plate is a re-org of the threat model  
page to allow for tracking of which threats we'll be tackling at which  
phase of the project (and how), and which not at all.  Thanks,
   Lucas.

>
> --BDS
> _______________________________________________
> dev-tech-dom mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-dom