Boris Zbarsky wrote:
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
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
