I submitted this as a potential security vulnerability to the Chromium bug
list but it didn't seem to register there. It's not a vulnerability in that
it has an imminent impact on anything, but I would still classify it as one
because of the fundamental level its active at, it's near
ubiquitous presence in past and present version of JS engines, its
incredible specificity in most cases, and the fact that it's completely
impossible to prevent without changing at the engine level.
To sum up: JS by nature of not having tail call optimization has maximum
stack frames as a matter of course and it's generally an early fail. The
interesting thing is that with a little bit of try catch you can determine
the maximum stack size before the limit was reached. A novel triviality on
its own but the really interesting thing is a combination of two odd facts:
the maximum stack size varies on almost every js engine between may minor
versions (and of course against other engines), and yet it's also extremely
stable and predictable for a given version.
The ultimate result is that it's trivial to determine to a very precise
range not only what engine you're running or even what version it is, but
the minor version as well. And the only requirements for you to be able to
do this are try catch and recursively calling your own function, so it's
(as far as I know) impossible to prevent in any sand boxing effort that I'm
aware of.
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.
This was the reproduction case I had, specifically for Chrome, but it works
the same in all but ont case
*REPRODUCTION CASE*
setTimeout(function(){var i=0; try{(function
m(){++i&&m()}())}catch(e){console.log(i)}}, 1)
Which produces (give or take a few);
17 Release (v8 3.7@10585): 18762
18 Dev (v8 3.8@10945): 18747
19 Canary (v8 3.9@10875): 18751
node (v8 3.9@10896): 18703
The code in question for some reason simlpy causes my current version of
Firefox to infinitely execute. I do know this works in spidermonkey itself
so I'm not sure what the issue is currently. I'm sure it'd just requiring
rejiggering it to prevent whatever is preventing the stack frame bailout.
The interesting thing is that this in most cases is stable across platforms
and archtiectures. And in the few cases its not, that's just more
information you have exposed and capturable.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
