Le 20/03/2012 16:28, Mark S. Miller a écrit : > On Tue, Mar 20, 2012 at 12:51 PM, David Bruant <[email protected] > <mailto:[email protected]>> 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? Mostly because of what you said below: "With translation, verification, or direct implementation, it can do what Joe-E and Erlang do: abort the process, abandoning all possibly corrupt state."
> What do you mean by "controlled"? Limiting the total amount of memory > is not the issue. The original issue came from the fact that untrusted code can get information out of the maximum call stack size. With rewriting, it could be possible to set the call stack size of untrusted code to an aribitrary number that doesn't leak information on the platform (obviously "arbitrary" under the limitation of the platform itself) > 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. I didn't send my message for days because I was trying to think about how to solve this particular issue. > (...) > 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. And indeed, aborting sounds like that's what should be done. Although implementations currently agree on a catchable error for maximum stack frame, it is not part of ECMAScript. Alongside with tail call optimisation, this could (and probably should) be part of an optional part of the next standard. > In the browser context, we could perhaps force a reload. I think that the rationale behind continuing the execution of JavaScript even when a maximum call number has been reached is that, in some cases, it may not corrupt the state and the user can continue to interact with the page even if there has been one exception. Unfortunately, I don't really know when it's true and when it isn't. Forcing a reload of the page would be terrible from a UX persective. A more conservative approach could be to disable JavaScript in the page (as with the NoScript Firefox add-on) and display a message like "an error happened on this website. It may not be as interactive.". This way, links and forms are still available. It would also prevent reloading a page that would reach the maximum call number when run (causing permanent reloading). Alternatively, a script could be provided as "backup". If the browser disables JavaScript, it sweeps all the objects, pending messages, etc. in the ECMAScript environment (except the minimum to provide what HTML+CSS would provide) and runs the backup script in a fresh environment (+ previous DOM). Since the environement is safe, there is no state corruption. There might be in the DOM, but the backup script can check for that. I don't really know how the backup is safely provided. First run first serve, probably? A vat contains a stack and a queue. Although these are used for different purposes, it seems that the error handling mechanism used when abusing of them is different. The stack throws a catchable error while the exhausting the queue will result in a a browser crash out of memory exhaustion. I wonder what makes both so different. My guess is that it's only a matter of optimization. I would guess that a JavaScript stack is mapped into a "system stack". While I see the benefit from this at small scale, I don't understand why the JavaScript call stack could not continue in the process heap so that recursive calls could continue until memory exhaustion. It makes me curious. David
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
