[TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Brendan Eich]

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  
are.

> 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  
address.

* 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  
> intrinsics.

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  
public outputs.

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.

/be

[*] http://www.informatik.uni-trier.de/~ley/db/journals/cacm/ 
cacm19.html (ACM members: http://portal.acm.org/citation.cfm? 
id=360056 -- anyone know of a free version?)