Hi Brandon, as a vulnerability, I admit it doesn't register much on me either. Such version detection is not something I imagined we could prevent and it has never really been on my radar to try. Nevertheless, your experiments are interesting.
But the catchable out-of-memory errors you observe do cause a different kind of vulnerability: < http://code.google.com/p/google-caja/issues/detail?id=460>. Your demonstration of the predictable regularity of these errors does make this vulnerability more exploitable. Joe-E addresses this my making all non-deterministic errors, including java.lang.OutOfMemoryErrors, non-catchable, so that no computation can occur in the (likely corrupt) computation state following such an occurrence. See < http://www.eros-os.org/pipermail/e-lang/2007-January/011817.html> for one of many discussions. This also echoes the Erlang fail-fast philosophy. 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. On Sat, Mar 10, 2012 at 2:03 PM, Brandon Benvie <[email protected]>wrote: > 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 > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
