Using max stack limit to determine current js engine and revision

David Bruant bruant.d at
Tue Mar 20 12:51:18 PDT 2012

Le 10/03/2012 23:03, Brandon Benvie a écrit :
> It's not really a security vulnerability on its own, but it does mean
> that as of current it's impossible to prevent
> executing JavaScript from being able to precisely determine under what
> conditions its running in almost all cases without being able to patch
> the engine. Being able to target specific versions is a key tool
> though in the arsenal of exploiting vulnerabilities.
I have been thinking about this for days and still can't really say if
it's true or false. In a way, this kind of information retrieval is a
form of browser sniffing.
If I was in possession of different hacks, I would just try them out in
a "feature testing" fashion. Instead of figuring out which platform I'm
on, I just try to see if the platform I'm running on is vulnerable to
breach I have found. Worst case, I'm not on the right platform and my
attempt fail. It couldn't work anyway.

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

So I don't see a use for the language to address this particular issue.


More information about the es-discuss mailing list