Safe, Closure-free, Serializable functions

Aymeric Vitte vitteaymeric at gmail.com
Thu Sep 26 00:40:40 PDT 2013


This is similar to the "Native" thread as Andrea mentioned.

Then when SES is coming?

It seems urgent to boost it, I have tried CSP recently, or at least what 
works today, see [1] and [2], unfortunately I don't see quite well what 
it does secure, today and tomorrow.

Regards,

Aymeric

[1] http://lists.w3.org/Archives/Public/public-webappsec/2013Sep/0058.html
[2] http://lists.w3.org/Archives/Public/public-webappsec/2013Sep/0067.html

Le 26/09/2013 02:32, Mark S. Miller a écrit :
> Hi François, your goals here have a tremendous overlap with SES. In 
> what ways is SES not satisfactory for these purposes?
>
> The best short-but-accurate summary of SES, sufficient for this 
> question, is <http://research.google.com/pubs/pub40673.html> section 2.3.
>
> SES does not remove eval and Function, but rather replaces them with 
> confining equivalents which should be better for your purposes. You 
> can get SES from either 
> <``https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/> 
> or <https://code.google.com/p/es-lab/source/browse/trunk/src/ses/>.
>
> The security of SES is analysed at 
> <http://theory.stanford.edu/~ataly/Papers/sp11.pdf 
> <http://theory.stanford.edu/%7Eataly/Papers/sp11.pdf>>.
>
>
> On Wed, Sep 25, 2013 at 4:29 PM, François REMY 
> <francois.remy.dev at outlook.com <mailto:francois.remy.dev at outlook.com>> 
> wrote:
>
>     Hi,
>
>     TLDR ==> The web needs a way to express executable code that does
>     not rely on its parent context, is guaranteed to be
>     side-effect-free, and can be executed safely anywhere (even in a
>     different thread/worker/window/device, or as callback for browser
>     code being executed while the DOM is not ready to be accessed)
>
>
>     It's been some time I've been working on this idea of a
>     Closure-free, Serializable function. This kind of function would
>     have no access to the parent closures they are defined in, and
>     only limited (read-only) access to the enclosing environment
>     (read-only Math, Object, Array, others...).
>
>     To the difference of other functions, those objects would not be
>     affected by the JavaScript running elsewhere on the page, so in
>     this closure-free function, Array.prototype.slice is guaranteed to
>     be the native slice function, not some kind of polyfill or
>     replaced function.
>
>     |    function sort(array) as serializable {
>     |        Array.prototype.sort.call(array);
>     |    }
>
>     |    function sqrt(number) as serializable {
>     |        return Math.sqrt(number);
>     |    }
>
>     |    function __BAD_CODE__() as serializable {
>     |        return new XMLHttpRequest(); // xhr not defined in ES6
>     |    }
>
>     Trying to export a global variable or modify any of the host
>     environment-defined objects would fail.
>
>     |    function __BAD_CODE__(number) as serializable {
>     |        globalNumber = number; // cannot write into the global object
>     |    }
>
>     |    function __BAD_CODE__() as serializable {
>     |        Object.prototype.doSomething=function() {}; // cannot
>     write into the native objects
>     |    }
>
>     It's also important to note that any Object or Array created
>     inside this context will be passed to the calling context by
>     deep-cloning (or by replacing the "safe" Math object by the host
>     Math object of the calling code in the case of environmental
>     objects). Objects that can't be cloned (non-serializable
>     functions, for example) are just transformed into null. We could
>     also maybe use the idea of a proxy though deep-cloning seems safer.
>
>     This makes sure it's impossible to leak the "safe" objects to the
>     calling context in any way (ie: the calling code can leak anything
>     to the called code, but not the reverse).
>
>     |    var RealSin = Math.sin;
>     |    Math.sin=function() {};
>     |
>     |    function giveMeMath() as serializable {
>     |        return [Math, Math.sin];
>     |    }
>     |
>     |    var [m,s] = giveMeMath();
>     |    // s === RealSin
>     |    // m === Math
>     |    // m.sin !== RealSin
>     |
>     |    // note that another possibility here
>     |    // would be to have giveMeMath return [null,null]
>     |    // (ie: consider host objects unserializable)
>
>     To be honest, those functions are not really meant to expose new
>     objects: even if they need some internally, they should just keep
>     them internally and avoid distributing them. The deep-cloning
>     algorithm is just there for the cases where you want to return
>     multiple values at the end of a function, or when you need an
>     options object.
>
>     Still, the fact they run in a "safe" environment makes them a good
>     candidate for further optimization and inlining, so we may end up
>     seeing codes written as serializable to benefit from performance
>     boost and safety from external attacks.
>
>     |    function Point(x,y) as serializable {
>     |        x = +x;
>     |        y = +y;
>     |        return {
>     |            x:x,
>     |            y:y,
>     |            r: Math.sqrt(x*x+y*y),
>     |            t: Math.atan(x,y)
>     |        };
>     |    }
>
>     The arguments, however, could be any object, and those act totally
>     normally. If an object is given as argument to the function that
>     is an Object, the function can access the "real" Object.prototype
>     by using Object.getPrototypeOf(...).
>
>     |    window.newXHR = function newXHR(window) as serializable {
>     |        return new this.XMLHttpRequest();
>     |    }
>     |
>     |    var xhr = window.newXHR();
>
>     However, it's also possible for the calling code not to give such
>     information by passing only primitive values like string and
>     numbers. I believe this is the most likely usage of this kind of
>     function, at least from the web platform point of view.
>
>
>
>     The good thing about those functions, is that they can safely be
>     sent over the wires to another thread, or to another web page,
>     because they do not possibly rely on any state or context.
>
>     Formalizing those functions is also an important step towards
>     enabling JS code to run safely deeper into the browser stack, by
>     avoiding any possible use of objects that are not supposed to be
>     interacted with at a given time (the calling code can control
>     exactly what the called function has access to).
>
>     A possible use case would be to defined arbitrary timing function
>     for animations:
>
>     |    function x2(x) as serializable { return x*x; }
>     |
>     |    // this is safe because SomeWebAnim knows he will call the
>     function
>      only with numbers, so the code cannot access the DOM while it's still
>     being computed, or because the DOM actually lives in another
>     thread than
>      the animation code.
>     |    SomeWebAnim.timingFunction = x2;
>
>
>
>     Is there some interest from anyone else in formalizing this for a
>     future version of EcmaScript? Or any comment?
>     Francois
>
>
>
>     PS: for the purposes of safety, we may want to disallow "eval" and
>     "Function" inside this environment to make sure the code can be
>     compiled ahead of time in all cases, and not force the usage of an
>     interpreter. this could also be let to the choice of the author
>     but be exposed as a slightly different concept (ie: compilable +
>     serializable vs serializable only).
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> -- 
>     Cheers,
>     --MarkM
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130926/2b3e53a2/attachment.html>


More information about the es-discuss mailing list