Using max stack limit to determine current js engine and revision

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Mar 21 01:59:11 PDT 2012


not sure if it's setTimeout problem but this snippet

(function (Function, MAX_EXECUTION_STACK) {
  if (MAX_EXECUTION_STACK in Function) return;
  Function[MAX_EXECUTION_STACK] = function (i) {
    try {
      (function max(){
        ++i && max();
      }());
    } catch(o_O) {
      return i;
    }
  }(0);
}(Function, "MAX_EXECUTION_STACK"));
// browser dependentalert(Function.MAX_EXECUTION_STACK);


from here:
http://webreflection.blogspot.com/2012/02/jsonstringify-recursion-max-execution.html

never gave me problems.

br

On Tue, Mar 20, 2012 at 9:28 PM, Mark S. Miller <erights at google.com> wrote:

> On Tue, Mar 20, 2012 at 12:51 PM, David Bruant <bruant.d at gmail.com> wrote:
>
>> Mark Miller:
>> > As an ES5 library without code verification or rewriting, there's
>> > nothing that SES can reasonably do about this. Perhaps this is
>> > something to address eventually once SES is made into a de jure
>> standard.
>> I see 2 cases:
>> 1) The untrusted code is being run in a sandbox. This sandbox can decide
>> to do some rewriting before running the code and I'm confident the stack
>> size and even message queue size can be controlled by the sandbox.
>>
>
> Why are you confident? What do you mean by "controlled"? Limiting the
> total amount of memory is not the issue.
>
> The issue I worry about, as indicated by my previous links to <
> http://code.google.com/p/google-caja/issues/detail?id=460> and <
> http://www.eros-os.org/pipermail/e-lang/2007-January/011817.html>, is an
> attacker causing a defender to lose integrity by causing the defender to
> abort forward execution at an unexpected and vulnerable point, but for
> execution to then proceed among the defender's objects after this
> occurrence.
>
> To stress the problem, I like to pose the following puzzle to Java
> programmers:
>
> You are given a properly formed conventional doubly linked list. Write a
> function which, when called, will attempt to splice in an element.
> a) If no exceptional conditions occur, the function must return in a state
> where the splice succeeded.
> b) Under all exceptional conditions allowed by the Java and JVM contracts,
> if the function exits (whether by return or throwing), it must exit in a
> state in which the doubly linked list is still well formed. The splice may
> or may not have occurred.
> You may assume only one thread is executing.
>
>
> The reason that all conventional answers to this challenge fail is that a
> JVM VirtualMachineError (including an OutOfMemoryError) can be thrown
> between any pair of instructions. In order to succeed at goal #a, at some
> point one of the doubly linked list's pointers need to be updated, leaving
> the list ill formed. After that, a VirtualMachineError may be thrown. We
> might put the whole thing into a try/catch or try/finally to try to restore
> the list to its original state in this circumstance, but another
> VirtualMachineError may prevent any progress there as well. The only
> solution is for the function *not* to exit once the shared data structure
> it is to update might be in an ill-formed state.
>
> Getting back to SES, SES as a library on ES5 without translation or
> verification cannot solve this puzzle. With translation, verification, or
> direct implementation, it can do what Joe-E and Erlang do: abort the
> process, abandoning all possibly corrupt state. In the browser context, we
> could perhaps force a reload.
>
>
>
>> 2) The untrusted code runs un-sandboxed like if it was trusted code
>> (thanks to an XSS or whatever reason). In that case, it often means that
>> you're in bigger trouble than the untrusted code being able to figure
>> out the specific version of your platform.
>>
>
> I'm not worried about untrusted code being able to figure out what
> platform it's on. I do not think it useful to try to address that threat
> model, including for the reasons you state.
>
>
>>
>> So I don't see a use for the language to address this particular issue.
>>
>
> depends what issue you're worried about ;).
>
>
>
>>
>> David
>> _______________________________________________
>> es-discuss mailing list
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120321/94b19632/attachment-0001.html>


More information about the es-discuss mailing list