brendan at mozilla.org
Wed Oct 31 10:21:27 PDT 2007
On Oct 31, 2007, at 9:55 AM, Kris Zyp wrote:
> , and this sandboxed eval, with the getters and setters of ES4,
> developers can create safe sandboxes with host object wrappers with
> fine grained access control to enable cross site scripts to be
> loaded and executed with controlled limited ability to interact
> with environments. I think if we had these capabilities, the most
> gaping hole in browser security could be effectively dealt with.
There are lots of exploits. Gaping holes that careful JS coders can
close, with the right tools, should be closed -- first the right
tools are needed as you note. But defense in depth plus fallible
human nature mean that no one is ever careful enough. The crackers
find really subtle holes. Security is never "done". So while I am in
favor of something like Doug's proposal, I'm not so confident as you
> One thing could make this a little smoother would be a constructor
> for a global object, with it's own set of global values, Object,
> Array, etc. for the sandboxed code to mutilate. Nice, but I don't
> think necessary.
This is exactly the path we went down. Obviously my a + b * c == 42
example is a useless toy. Real uses of eval like this will want to
evaluate complex object graphs, possibly even containing functions.
It's a sandbox, right? Should be safe. Not so fast:
* Information can flow out of the sandbox as well as into it from the
evaluated string. What result types should be allowed? If dynamic
objects, see below.
* From GreaseMonkey experience, the trusted caller of evaluate often
wants to add new API functions and objects to the sandbox. This
cannot be done safely in ES3. Among other problems are the mutable
prototypes, and Function.prototype.call/.apply which fixtures do
* This kind of sandbox is a leaky reference monitor in general. There
is no mandatory access control specified for all control flows.
Implicit flows[*] are unmonitored. We have experience going back to
Netscape 4 (and earlier) that such a system is "advisory" -- people
may use it, or not; they may use it in one place and not in another;
they may use it but it's easy to leak information across the sandbox
object reference, and out from the return value.
Some proposals have insisted on primitive types only as the result.
That's insufficient, and judging from real web apps and add-ons such
as GM, crippling.
> Perhaps, I am missing something, and I don't know for sure how to
> capitalize the s in security, but this seems a way more valuable
> asset to security than constraints provided by fixtures and
Please don't set up a false dilemma.
As noted above, without fixtures and other mutability controls
missing from ES3, you can't safely inject added APIs into the
sandbox. You can't even trust the sandbox object after the evaluate,
in the sense that even getting a property from an object in it might
trigger a getter, with unexpected results. The trust label for the
getter's code should be other than the trust label of evaluate's
caller, of course, and perhaps there is a reference monitor comparing
those labels somehow.
But now the mission creep has turned into a whole new, extremely
"researchy", mission, until ES4 specifies mandatory access control
(MAC) and even non-interference: secure information flow: public and
secret inputs to a program only mix in secret outputs, never in
Security is never simple, and from our experience in Mozilla, it
actually hurts to be simplistic about things like an eval sandbox.
Nevertheless! I'm in favor of something like Doug's proposal, but it
needs a vigilant detailing and critical thinking about the issues you
raise, and others. These issues are not peripheral or minor:
* populating the sandbox with standard objects,
* populating it with custom objects,
* explicit result type restrictions,
* sandbox side effect hazards, including code (getters on objects in
the sandbox, etc.)
* (from the last point) mutation controls in general -- new in ES4,
not in ES3
* real end-to-end MAC for implicit flows, information security.
cacm19.html (ACM members: http://portal.acm.org/citation.cfm?
id=360056 -- anyone know of a free version?)
More information about the Es4-discuss