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. David _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
