336559 - Investigate a better security model for injecting functions into evalInSandbox

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Blake Kaplan (:mrbkap) (inactive)]

Currently, the accepted model for injecting functions into Components.utils.evalInSandbox is to simply stick the functions on the sandbox object itself. So, in a JavaScript component, one might do:

var box = new Components.utils.Sandbox(someURL);
box.foo = myFoo;
box.bar = myBar;
Components.utils.evalInSandbox(untrustedScript, box);

As we saw in bug 321101 and friends, this lends the untrusted script unwarrented access to the calling (chrome) code, giving it a handle which it might be able to use to pull itself out of the sandbox and run chrome code. For bug 321101 (or, more specifically, bug 319263), we decided to plug all known holes that could lead out of the sandbox, but that is really a stopgap solution. We should come up with a better way of exposing functions.

bug 321101 comment 20 describes one such solution. It has the advantage that all objects in the sandbox are created in the sandbox, so following anybody's __proto__ or __parent__ chain won't get you anywhere. The major hurdle to that solution, however, is that a chrome function that returns an object (as opposed to a primitive, such as a string) re-opens the hole. The patch in that bug attempts to use (basically) |return eval(uneval(rval))|. However, this fails pretty quickly for native objects.

I'm filing this bug to find a solution that makes everybody happy (whether we continue with bug 321101's approach or find a better one).

Comment 1

[Blake Kaplan (:mrbkap) (inactive)]

bug 386635 fixed this, IMO.