 |
Newsgroups: mozilla.dev.platform
From: John J Barton <johnjbar...@johnjbarton.com>
Date: Wed, 13 Oct 2010 14:24:04 -0700
Local: Wed, Oct 13 2010 5:24 pm
Subject: Re: Accessing unsafe properties
Boris Zbarsky wrote: No, I am specifically excluding plugins and extensions: I want to be > On 10/13/10 1:54 PM, johnjbarton wrote: >>>> We need to know which of those operations are safe and >>>> which are not safe. >>> So what's the list of operations involved as you see it? >> Let's see. Global functions of browser.xul. Global functions and methods > Or with arbitrary extensions that override those services, right? responsible for the things we can change, not the things we cannot. The potential for another extension to introduce a security hole does not absolve us from trying to close ours. I need to analyze our code. If I see foo = bar; where I know that foo is a obtained as a property (of a property...) of wrappedJSObject, what shall I do: 1) remove that code, it is unsafe, 2) analyze bar, but how?? 3) no worries, the platform secures it. Is that clearer? >>> Uh... pessimistic in what sense? >> In the sense that this security analysis is hopeless. I'm trying to > No, I think in the scope you stated at the beginning of the mail above >> To be clear I'm not asking for completeness with respect to analyzing > And I'm just saying that this is already a sufficiently large list of jjb You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||
|
Newsgroups: mozilla.dev.platform
From: Boris Zbarsky <bzbar...@mit.edu>
Date: Wed, 13 Oct 2010 21:08:47 -0400
Local: Wed, Oct 13 2010 9:08 pm
Subject: Re: Accessing unsafe properties
On 10/13/10 5:24 PM, John J Barton wrote:
> No, I am specifically excluding plugins and extensions: I want to be The point is that an extension can change the behavior of a service in a > responsible for the things we can change, not the things we cannot. The > potential for another extension to introduce a security hole does not > absolve us from trying to close ours. way that is safe on its own in general but happens to be unsafe in combination with the specific way you're using the service. It might not even have any way to tell that your use will cause a problem. >> I'm not sure I follow the above. This is the part I don't get. Is the actual code of the form |foo = > I need to analyze our code. If I see bar;| (i.e. with a bareword on the LHS)? If so, what does it mean that "foo is obtained as a property" of anything? If not, what form does the code actually have? > 1) remove that code, it is unsafe, Not quite; see above. > 2) analyze bar, but how?? > 3) no worries, the platform secures it. > Is that clearer? > So what do we do then? Wait and see if users get exploited? Well, if your list of possible things you actually _do_ as opposed to might do, is short enough we could analyze each of them. If it's very long, then you have a fundamental problem, yes.... It might be solvable via fuzz testing, or restricting what things are done, or hiring a few people for a year or two to analyze all the possibilities. :( -Boris You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||
|
Newsgroups: mozilla.dev.platform
From: johnjbarton <johnjbar...@johnjbarton.com>
Date: Fri, 15 Oct 2010 08:58:53 -0700
Local: Fri, Oct 15 2010 11:58 am
Subject: Re: Accessing unsafe properties
On 10/13/2010 6:08 PM, Boris Zbarsky wrote:
> On 10/13/10 5:24 PM, John J Barton wrote: Does that mean we should not bother with any security issues? If not >> No, I am specifically excluding plugins and extensions: I want to be >> responsible for the things we can change, not the things we cannot. The >> potential for another extension to introduce a security hole does not >> absolve us from trying to close ours. > The point is that an extension can change the behavior of a service in a amount of work on our part will prevent security issues, then we may as well not bother? I don't think that is what you mean. So I guess we just have to live with this exotic possibility, do our best, and assume this case won't come up in practice. Does this mean that the only option is: 4) post the code and ask Boris ? That seems very inefficient and error prone, especially when we have lots of releases. >> So what do we do then? Wait and see if users get exploited? > Well, if your list of possible things you actually _do_ as opposed to know what those restrictions are. Even an overly limiting list of things that are ok plus "you may ask about xxx" plus "don't do yyy" would be great. jjb You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||
|
Newsgroups: mozilla.dev.platform
From: Boris Zbarsky <bzbar...@mit.edu>
Date: Fri, 15 Oct 2010 13:53:37 -0400
Local: Fri, Oct 15 2010 1:53 pm
Subject: Re: Accessing unsafe properties
On 10/15/10 11:58 AM, johnjbarton wrote:
>> The point is that an extension can change the behavior of a service in a The right way to handle security issues is: >> way that is safe on its own in general but happens to be unsafe in >> combination with the specific way you're using the service. It might not >> even have any way to tell that your use will cause a problem. > Does that mean we should not bother with any security issues? If not 1) Reduce attack surface as much as possible (in this case, reduce In particular, the right way to handle issues with services being options are either to understand the system well enough to tell whether it is (and knowledge of the code is probably needed to decide what parts of the system are relevant), or to show the code to someone else and ask them to look. It doesn't have to be "Boris". This is why we have code reviews. Sometimes by multiple people if Now I'm happy to help you along on the "understand the system" bit, > I'm perfectly fine with "restricting what things are done", but we don't 1) You can read properties from content objects, and the act of reading > know what those restrictions are. Even an overly limiting list of things > that are ok plus "you may ask about xxx" plus "don't do yyy" would be > great. them is safe. The result also satisfies this property. 2) You can safely set properties on content objects to primitive values. 3) You can safely set properties on content objects to object values, 4) You don't want to pass anything coming from content to any place that 5) You don't want to allow content to directly call chrome-privilege OK. What things not on that list are of interest? -Boris You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||
|
Newsgroups: mozilla.dev.platform
From: John J Barton <johnjbar...@johnjbarton.com>
Date: Fri, 15 Oct 2010 15:53:29 -0700
Local: Fri, Oct 15 2010 6:53 pm
Subject: Re: Accessing unsafe properties
Boris Zbarsky wrote: ... > On 10/15/10 11:58 AM, johnjbarton wrote: Excellent! This is exactly the kind of thing I was looking for! Well the functions we might use in a content page. Again I'm not asking for a comprehensive list, just a few things we know are safe. I believe that chrome code called from content can: 1) read content objects, 2) assign content objects to content objects, 3) call DOM platform methods and pass content objects. 4) assign strings obtained from content objects to chrome object properties, 5) assign strings obtained from chrome objects to content objects 6) avoid passing content objects into chrome functions unless you can ensure that you don't violate the rest of the guidelines. 7) beware that chrome functions can close over chrome objects. It seems to me that at lot could be gained here if the chrome code was You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||
|
Newsgroups: mozilla.dev.platform
From: Boris Zbarsky <bzbar...@mit.edu>
Date: Fri, 15 Oct 2010 21:11:21 -0400
Local: Fri, Oct 15 2010 9:11 pm
Subject: Re: Accessing unsafe properties
On 10/15/10 6:53 PM, John J Barton wrote:
>> 5) You don't want to allow content to directly call chrome-privilege "recursively". ;) Basically assume that the page can pass arbitrary >> functions unless they have been _very_ carefully vetted and you >> understand completely all places that content-controlled data can >> reach via those functions. >> OK. What things not on that list are of interest? > ....in #5 we face the same kind of issue again: we don't know how to vet arguments of its choosing, and make sure your function deals with any behavior on their part. > 1) read content objects, Mostly yes, though if you violate same-origin restrictions in #3 there > 2) assign content objects to content objects, > 3) call DOM platform methods and pass content objects. (which you can do, as chrome) you can lose. > 4) assign strings obtained from content objects to chrome object If you're guaranteed that they're strings, and if you're careful about > properties what you do with those chrome object properties, yes. > 5) assign strings obtained from chrome objects to content objects Yes. > 6) avoid passing content objects into chrome functions unless you can Yes. > ensure that you don't violate the rest of the guidelines. > 7) beware that chrome functions can close over chrome objects. You can also make network requests or read the filesystem and combine > It seems to me that at lot could be gained here if the chrome code was That's possible, yes. > compiled in a sandbox with a limited scope. -Boris You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||
|
Newsgroups: mozilla.dev.platform
From: johnjbarton <johnjbar...@johnjbarton.com>
Date: Sat, 16 Oct 2010 22:00:57 -0700
Local: Sun, Oct 17 2010 1:00 am
Subject: Re: Accessing unsafe properties
I wrote a summary of the lists at the end of this thread here:
http://getfirebug.com/wiki/index.php/Using_win.wrappedJSObject jjb You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||
|
Newsgroups: mozilla.dev.platform
From: Steven Roussey <srous...@gmail.com>
Date: Fri, 10 Dec 2010 19:59:28 -0800 (PST)
Local: Fri, Dec 10 2010 10:59 pm
Subject: Re: Accessing unsafe properties
> > I assume that What about evalInSandbox? That seems like it will be more unsafe > > var x = <webpage-object>.wrappedJSObject.foo; > > is safe at all times. > Yes. At least if it's not, we have a _really_ serious bug. The whole according to the docs[1]: -------------------- } var y = x.y; /* this is unsafe */ -------------------- So: x = extensionWindowReference.wrappedJSObject.someGlobalVar; is far safer, correct? What if I want to call a function on this global object? x = Is that unsafe? Should I instead: var s = new Components.utils.Sandbox(extensionWindowReference); But then x is really unsafe now, so then what? Do I use the The sandbox stuff doesn't say anything about objects getting wrappers. [1] https://developer.mozilla.org/en/Components.utils.evalInSandbox You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||