references to trusted objects from untrusted contexts
Fritz Schneider
when JavaScript crosses contexts. The XPCNativeWrapper doc[*] does a
great job of covering access to untrusted objects by trusted scripts,
but not such much the other way around. In particular, this access
matrix seems to imply something dangerous:
-----------------------------------
What happens when a script accesses an object?
Script Object Effects
Protected Trusted No wrapper is created and therefore the script
gets full access to the object.
...
Unprotected Trusted No wrapper is created, just as in the
protected/trusted case.
...
-------------------------------------
If I understand this correctly, if I give an unprotected script a
reference to a trusted object, that script has full access to the
object? For example, if I give a script in a web page a reference to
an object instantiated in a js XPCOM component, that script could
replace someobject.prototype.foo? That seems so dangerous that I think
I must be mis-reading this doc or missing some part of the equation...
Perhaps someone could walk me through (or better yet, post a page that
walks someone through) the algorithm that's used to make these kinds
of determinations, as well as the explicit security policy the
algorithm is designed to implement.
(BTW, side question: we've been playing around with executing
maybe-untrusted scripts in a sandbox and am trying to reason out why
you can't set sandbox.alert = trustedWindow.alert, but you can set
sandbox.alert = function(x) { trustedWindow.alert(x); };)
Boris Zbarsky
> If I understand this correctly, if I give an unprotected script a
> reference to a trusted object, that script has full access to the
> object?
There are some security checks, but they're done by XPConnect. Brendan or Blake
might know more about whether there are any JS eng. checks that happen in cases
like this...
> For example, if I give a script in a web page a reference to
> an object instantiated in a js XPCOM component, that script could
> replace someobject.prototype.foo?
Doesn't seem to be able to (I get a security exception accessing .__proto__ on
the privileged object).
Imho, you shouldn't be doing this even if it turns out there's some check
somewhere that saves someobject.prototype.foo.
> Perhaps someone could walk me through (or better yet, post a page that
> walks someone through) the algorithm that's used to make these kinds
> of determinations, as well as the explicit security policy the
> algorithm is designed to implement.
As far as I know, the basic policy is "script MUST NOT be able to get references
to objects from another trust domain with a very few exceptions (window objects,
say)". Any time it does, that's a bug. If your extension is letting content
scripts have such access, your extension has a bug,
> (BTW, side question: we've been playing around with executing
> maybe-untrusted scripts in a sandbox and am trying to reason out why
> you can't set sandbox.alert = trustedWindow.alert, but you can set
> sandbox.alert = function(x) { trustedWindow.alert(x); };)
The |alert| function on windows expects its |this| object to be of a certain
type and will throw if it's not.
-Boris
Fritz Schneider
MDC is incorrect, and the real security policy is folklore that even
experienced developers (like Boris) have to guess at?
Tell me it ain't so.
Brendan Eich
> Fritz Schneider wrote:
>> If I understand this correctly, if I give an unprotected script a
>> reference to a trusted object, that script has full access to the
>> object?
>
> There are some security checks, but they're done by XPConnect. Brendan
> or Blake might know more about whether there are any JS eng. checks that
> happen in cases like this...
This direction of access (untrusted is handed a "trusted" object by
trusted code) is not safe. We grew like topsy and have not fixed our
security checks to compute the "meet" (greatest lower bound) of all
active principals on the stack when checking access. So if the trusted
object is implemented using JS, you are in trouble handing it to any
untrusted code.
bz and roc proposed the meet fix, we should do it. Boris, is a bug on
file yet?
>> For example, if I give a script in a web page a reference to
>> an object instantiated in a js XPCOM component, that script could
>> replace someobject.prototype.foo?
>
> Doesn't seem to be able to (I get a security exception accessing
> .__proto__ on the privileged object).
That's because of one of those JS-level checks (JS calls the hook, the
CAPS code implements it).
We check __proto__, __parent__, <class-prototype>.constructor, and
scripted getter or setter.
> As far as I know, the basic policy is "script MUST NOT be able to get
> references to objects from another trust domain with a very few
> exceptions (window objects, say)". Any time it does, that's a bug. If
> your extension is letting content scripts have such access, your
> extension has a bug,
This reflects our building unsoundly on top of the web same-origin
policy, which soundly checks access at window boundaries. We need a new
model for the evolved chrome+user-scripts+content world. I'm working on
this, in particular by recruiting someone I think is ideal for the job.
More in a bit.
/be
Boris Zbarsky
> So -- sorry if this is harsh -- the security policy as documented on
> MDC is incorrect
MDC doesn't have a security policy documented that I'm aware of. The
XPCNativeWrapper docs document when wrappers are created. Nothing more, nothing
less. A security policy would describe the conditions under which a given
subject can perform a given operation on a given object, or at least the general
rules that apply to such situations.
> and the real security policy is folklore that even
> experienced developers (like Boris) have to guess at?
Somewhat, yeah.
More precisely, the real "base" security policy is what I said in my previous post:
Script must not be able to get references to objects from another trust domain
with a very few exceptions.
That's not much to go on, and it leaves open the question of what happens with
the exceptions. Further, bugs and actions by script often mean that the above
policy is violated. Also, CAPS allows disabling access to specific properties
of specific objects for specific subjects.
So there are also various checks of the form "given a subject (actor) and an
object, can the subject perform a specific action on the object?" that happen.
These will typically fail (if performed at all) when an unprivileged subject
accesses a privileged object. I say "if performed at all" because the code flow
is very different for XPConnect-wrapped natives and "native" JSObjects here. I
don't believe the latter end up in
nsScriptSecurityManager::CheckPropertyAccessImpl for random property access, for
example. Of course for "native" JSObjects the XPCNativeWrapper thing that
started this thread is also not relevant. I'm also not quite sure whether
XPConnect does these checks for only XPConnect-ified properties or all properties.
Finally, to deal with the objects that _can_ be accessed across trust domains
(eg windows), there is a set of security checks that windows peform on access to
their properties (see nsDOMClassInfo.cpp). Except they try to optimize these
away if they can, since they're expensive... I'm not sure how these fit in with
checks the JS engine itself does, though I think they do somehow.
Back to your point, though, none of this is documented anywhere that I'm aware
of. I certainly don't know all the pieces that go into this. I agree that this
is a problem; unfortunately I'm not sure anyone _does_ know how allthe pieces
fit together.
Perhaps we should start a wiki page and put down the parts we _do_ know and
understand; I bet between Brendan, Blake, Johnny, and myself we should be able
to put together a reasonably clear picture of what we _do_ (what we intend to do
should be derivable at that point, I hope).
-Boris
Boris Zbarsky
> bz and roc proposed the meet fix, we should do it. Boris, is a bug on
> file yet?
Not that I'm aware of. And it's not really clear enough in my head to file one;
certainly I'd prefer we get a hang of what security policy we're trying to
enforce first...
> That's because of one of those JS-level checks (JS calls the hook, the
> CAPS code implements it).
>
> We check __proto__, __parent__, <class-prototype>.constructor, and
> scripted getter or setter.
OK. Let's get that documented!
-Boris
Fritz Schneider
> trusted code) is not safe.
Then it sounds like it is the case that there is no possible way to
safely expose an interface to code in a sandbox? I'm playing with some
maybe-untrusted code in a sandbox, and was hoping to give it a way to
pass information out to my trusted code (e.g., by attaching
sandbox.foo = function() {} and letting the sandboxed code call foo),
aside from the result of evalInSandbox.
> > Doesn't seem to be able to (I get a security exception accessing
> > .__proto__ on the privileged object).
>
> That's because of one of those JS-level checks (JS calls the hook, the
> CAPS code implements it).
>
> We check __proto__, __parent__, <class-prototype>.constructor, and
> scripted getter or setter.
Why, though?
Fritz Schneider
> > This direction of access (untrusted is handed a "trusted" object by
> > trusted code) is not safe.
Is this due to bugs or policy? That is, in the absence of bugs in this
area, would this direction be safe?
And I suppose a logical followup would be: is there any way to make a
trusted object untrusted?
Fritz Schneider
In this particular instance we want to pass content from the page into
untrusted code, and then be able to have that code tell us a result
(also a primitive type, e.g., a string serialization of a map or
similar).
Monica Chew (cc'd above) has implemented this safely using
evalInSandbox. Basically, she calls into a fixed interface in the
sandbox that returns a string containing a representation of the
content the untrusted code is interested in as well as the name of the
function(s) to invoke with that data. For example, "title,url,a:hrefs
|| func1,func2,func3". The chrome driver then extracts these data from
the page, stringifies them, and then pieces them together into a
string appropriate to eval in the sandbox. For example, "var data =
{title: <value>, url:
<value>,...};func1(data);func2(data);func3(data)".
In the process of working this out, I was thinking two things.
First, that the trouble arises from giving references to _objects_ in
other contexts, but that often the reference to an object is a means
rather than an end. For example, we wanted to do sandbox.foo =
functionInTrustedContext to enable passing of data out of the context.
I suspect that for many applications, passing reference types isn't
strictly necessary; we're can get by with passing data so long as
there is a way to pass it.
So perhaps it might make sense to provide a safe, easy way to pass
_primitive data_ between contexts with different levels of trust. The
brower could provide a proxy service to do this. One context could
call:
var targetContext = // a window, a sandbox, an xpcom context
function consumer() {...}
proxy.registerInterface(targetContext, consumer, "sendData");
then in the target context code could call:
// causes consumer(someValue) to be called in first context
proxy.sendData(someValue);
// or maybe just sendData(someValue)
The proxy could enforce that someValue is a string, or could perhaps
do the serialization itself. I haven't thought this out much, but
perhaps there's something there.
The second thought that I had was that you could actually safely
execute code in one context on behalf of another using a serialization
of there were an easy way stringify code (and there is!). Suppose you
have some code that wants to operate on content but that you don't
want to have access to chrome. The chrome piece could get the string
representation of the code (e.g., the serialization of an object
encapsulating state as well as functions) from the untrusted context
via the proxy-like thing. Then it could eval it in the content context
and receive the results through a proxy call from within the content
(you can prevent the content from making spurious calls by only
enabling them when you know you're evaling). Or maybe via a return
value.
It's late and maybe I'm rambling, but I thought I'd throw it out
there. Or maybe people already do this kind of thing -- I haven't
looked at the state of the GM art in a while.
On 3/9/06, Brendan Eich <bre...@meer.net> wrote:
> Fritz Schneider wrote:
>
> This direction of access (untrusted is handed a "trusted" object by
> trusted code) is not safe.
>
> Then it sounds like it is the case that there is no possible way to
> safely expose an interface to code in a sandbox?
>
> We *think* we've secured the paths in the object graph that don't go
> through generic access checking code in window object get- and set-property
> hooks. We may have a few obscure paths to check, which are exposed only on
> certain kinds of objects, which may not be exposed via Firefox chrome to
> content (extensions are another story...).
>
> But, as noted earlier today in my previous reply, it seems like a bad idea
> to rely on each trusted object to be fully trustworthy, since the trust
> comes from inheritance, specifically from URI origin being chrome -- a
> blanket judgment that doesn't address individual weak links.
>
> So the greatest lower bound on trust labels for code active on the JS stack
> gives us a small, central, easily audited piece of code to trust. This
> "meet-computing" code automatically lowers privileges for all "trusted
> objects" whose methods might be called from untrusted code, even in very
> indirect ways. There may still be covert channels, but we need to address
> this very overt one first.
>
> Doing so sounds easier than it will prove to be, I bet. I believe (bz may
> remember off the top of his head) that we have code where content calls
> chrome (obvious example would be a dialog, say for a file upload widget or
> some such thing) and needs the callee to have greater privileges than the
> caller does.
>
>
> I'm playing with some
> maybe-untrusted code in a sandbox, and was hoping to give it a way to
> pass information out to my trusted code (e.g., by attaching
> sandbox.foo = function() {} and letting the sandboxed code call foo),
> aside from the result of evalInSandbox.
>
>
> We should talk more about the particulars. Better yet, we should implement
> the "meet" idea and diagnose the hard cases that it breaks, giving them
> better means to their hard-case ends. That way everyone's safer by default.
>
>
>
>
> Doesn't seem to be able to (I get a security exception accessing
> .__proto__ on the privileged object).
>
> That's because of one of those JS-level checks (JS calls the hook, the
> CAPS code implements it).
>
> We check __proto__, __parent__, <class-prototype>.constructor, and
> scripted getter or setter.
>
> Why, though?
>
>
> Because of the window-level access checks not sufficing in our extended
> world. In the DOM same-origin model, windows are articulation points in the
> graph of all objects, and also containers of objects that all have the same
> trust label within a given window. You can open another window and load a
> doc from a different origin in it. You shouldn't be able to read data from
> its DOM, though (you can write only to location, to navigate the window away
> to another document).
>
> So it is necessary to check access at window boundaries. It's also
> sufficient to identify objects in each window by their window's trust label,
> i.e. to link window and label, but not link every object in the window to
> the trust label (aka principal). Instead, we require security code that
> wishes to find the trust label for a contained object to follow the object's
> static scope (or parent, in SpiderMonkey jargon) chain up to the window.
>
> This avoids the cost of a trust-label slot per object, at the cost of short
> loops up the scope chain. (The scope chain link slot is unavoidable in
> SpiderMonkey and used by function objects and all DOM objects -- in ECMA-262
> Edition 3 it is specified for function objects as the [[Scope]] internal
> property). A user-constructed object obj whose constructor function is Ctor
> has obj.__parent__ === Ctor.__parent__. And top-level function objects are
> parented by the global object, which is the window in the browser embedding
> of JS. So, most objects are scoped directly by their window, with the
> obvious exception of the DOM level 0, wherein objects nest as their tags do
> (window contains document contains form contains form element contains event
> handler). Still, searching rather than linking every object to its
> principal is a good trade-off.
>
> Window-boundary access checking may appear to be secure, since each window
> gets its own copy of the JS standard objects, so all objects in a window,
> including the window itself, have Object.prototype as their ur-prototype
> object, and all objects are scoped by the window, which has a null scope
> chain link (__parent__ in SpiderMonkey).
>
> But it's not secure to access-check only at the window boundaries in
> Mozilla, because of our JS extensions, some of which go back eight or more
> years:
>
>
> SpiderMonkey exposes not only Object.prototype__defineGetter__ and
> Object.prototype.__defineSetter__, but also
> Object.prototype.watch. These are implemented internally using per-property
> getters and setters, hooks that are peculiar to the property named by the
> method. Therefore gets and sets on such properties, even if they are
> defined on a window object, bypass the class-generic window get- and
> set-property hooks that do the common access checking required for
> same-origin security.
>
> SpiderMonkey reflects __proto__ and __parent__ for all objects, again using
> per-property getter and (for __parent__) setter hooks. The ability to bind
> chrome XBL makes these hazardous without specific access checking. See
> https://bugzilla.mozilla.org/show_bug.cgi?id=296397.
> In the JS object model, a constructor function object C has a prototype, and
> C.prototype.constructor === C. Again XBL introduced hazards not found in
> the conventional DOM level 0 same-origin model. This was originally
> reported in
> https://bugzilla.mozilla.org/show_bug.cgi?id=296489, which
> was dup'ed against 296397.
> I will take the fifth on other hard cases, because I'm not sure the bugs
> have been patched in all older releases.
>
> /be
>
Boris Zbarsky
>>> Doesn't seem to be able to (I get a security exception accessing
>>> .__proto__ on the privileged object).
>> That's because of one of those JS-level checks (JS calls the hook, the
>> CAPS code implements it).
>>
>> We check __proto__, __parent__, <class-prototype>.constructor, and
>> scripted getter or setter.
>
> Why, though?
This is the sort of question a comprehensive security policy would answer and
the sort of question we often don't have stock answers for. :(
In this case, I think we do have an answer, though: "Someone found a situation
where an object and its __proto__ were in different trust domains, and our
policy is to not allow access to things from a different trust domain, so we
need to check when getting the __proto__." Similar for __parent__.
-Boris
Fritz Schneider
applications that require cross-context communication might be solved
with the combination of:
(1) easy object (de)serialization to/from strings and
(2) a proxy object that safely passes strings across contexts (via a
proxy model, producer/consumer, or whatever)
Perhaps I've reduced the problem to itself (how to protect the
proxy?), but I don't think so: you can basically do this with the
sandbox today, though it is a little ugly.
> > This direction of access (untrusted is handed a "trusted" object by
> > trusted code) is not safe.
> >
> > Doesn't seem to be able to (I get a security exception accessing
> > .__proto__ on the privileged object).
> >
> > That's because of one of those JS-level checks (JS calls the hook, the
> > CAPS code implements it).
> >
> > We check __proto__, __parent__, <class-prototype>.constructor, and
> > scripted getter or setter.
> >
Brendan Eich
> In this case, I think we do have an answer, though: "Someone found a
> situation where an object and its __proto__ were in different trust
> domains, and our policy is to not allow access to things from a
> different trust domain, so we need to check when getting the
> __proto__." Similar for __parent__.
For some reason, my post replying to the message from Fritz you're
replying to above has not shown up in the group yet.
I linked to specific bugs, which have to-do with chrome XBL being usable
from content. That's the root of much evil here. The rest comes from
old reflection facilities in SpiderMonkey (__proto__, __parent__) and in
ECMA-262 itself (constructor).
/be
Brendan Eich
> BTW, with respect to this statement:
>
>
>>> trusted code) is not safe.
>>>
>
> area, would this direction be safe?
>
There are a few unfixed bugs, but we don't think the default should be
for untrusted calling trusted to get trust. Fixing that should be done
centrally, in the "funnel" through which all policy decisions flow.
This is caps code, where instead of using the running script's
principals, or equivalent, we would compute the meet. So if Pcontent
calls Pchrome, the principals would be Pcontent. If somehow Pcontent1
called Pcontent2 called Pchrome, we would have Pcontent1 ^ PContent2
which is the null principal, and then Pnull ^ Pchrome which is Pnull.
So not much could be done by such a callee, unless it carefully elevated
privilege in a block-local fashion.
> And I suppose a logical followup would be: is there any way to make a
> trusted object untrusted?
Not currently. We (mrbkap and I at least) were talking about this when
we last talked to Aaron about better sandboxing for GreaseMonkey user
scripts. We talk too seldom, so this fell down the list.
Blake, feel free to jump in here.
/be
Brendan Eich
This direction of access (untrusted is handed a "trusted" object by trusted code) is not safe.
Then it sounds like it is the case that there is no possible way to safely expose an interface to code in a sandbox?
We *think* we've secured the paths in the object graph that don't go through generic access checking code in window object get- and set-property hooks. We may have a few obscure paths to check, which are exposed only on certain kinds of objects, which may not be exposed via Firefox chrome to content (extensions are another story...).
But, as noted earlier today in my previous reply, it seems like a bad idea to rely on each trusted object to be fully trustworthy, since the trust comes from inheritance, specifically from URI origin being chrome -- a blanket judgment that doesn't address individual weak links.
So the greatest lower bound on trust labels for code active on the JS stack gives us a small, central, easily audited piece of code to trust. This "meet-computing" code automatically lowers privileges for all "trusted objects" whose methods might be called from untrusted code, even in very indirect ways. There may still be covert channels, but we need to address this very overt one first.
Doing so sounds easier than it will prove to be, I bet. I believe (bz may remember off the top of his head) that we have code where content calls chrome (obvious example would be a dialog, say for a file upload widget or some such thing) and needs the callee to have greater privileges than the caller does.
I'm playing with some
maybe-untrusted code in a sandbox, and was hoping to give it a way to
pass information out to my trusted code (e.g., by attaching
sandbox.foo = function() {} and letting the sandboxed code call foo),
aside from the result of evalInSandbox.
We should talk more about the particulars. Better yet, we should implement the "meet" idea and diagnose the hard cases that it breaks, giving them better means to their hard-case ends. That way everyone's safer by default.
Doesn't seem to be able to (I get a security exception accessing .__proto__ on the privileged object).That's because of one of those JS-level checks (JS calls the hook, the CAPS code implements it). We check __proto__, __parent__, <class-prototype>.constructor, and scripted getter or setter.
Why, though?
Monica Chew
trusted object, but changes the type so that the sandbox can't
reference trusted APIs from the clone? Or, if the object is a
function, to make it so the sandbox can't introspect on the function?
> > > This direction of access (untrusted is handed a "trusted" object by
> > > trusted code) is not safe.
> > >
> > > Doesn't seem to be able to (I get a security exception accessing
> > > .__proto__ on the privileged object).
> > >
> > > That's because of one of those JS-level checks (JS calls the hook, the
> > > CAPS code implements it).
> > >
> > > We check __proto__, __parent__, <class-prototype>.constructor, and
> > > scripted getter or setter.
> > >
> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>
Monica Chew
The proxy model could emulate Linux the kernel's copy_to_user and
copy_from_user, but that leads to another question -- how do you
ensure you're using the proxy correctly, and not accidentally passing
in references.
> > > > This direction of access (untrusted is handed a "trusted" object by
> > > > trusted code) is not safe.
> > > >
> > > > Doesn't seem to be able to (I get a security exception accessing
> > > > .__proto__ on the privileged object).
> > > >
> > > > That's because of one of those JS-level checks (JS calls the hook, the
> > > > CAPS code implements it).
> > > >
> > > > We check __proto__, __parent__, <class-prototype>.constructor, and
> > > > scripted getter or setter.
> > > >
Brendan Eich
> 2. SpiderMonkey reflects __proto__ and __parent__ for all objects,
> again using per-property getter and (for __parent__) setter
Oops, I meant "(for __proto__)" before "setter" above -- __parent__ is
read-only.
This informal write-up contains some boss-level browser security
mechanism description, something never written down in any standard
spec. It needs to be codified more rigorously. I'll start a
wiki.mozilla.org page next week and post a link here.
/be