On Tue, Mar 20, 2012 at 12:51 PM, David Bruant <[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? What do you mean by "controlled"? Limiting the total amount of memory is not the issue. 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. To stress the problem, I like to pose the following puzzle to Java programmers: You are given a properly formed conventional doubly linked list. Write a function which, when called, will attempt to splice in an element. a) If no exceptional conditions occur, the function must return in a state where the splice succeeded. b) Under all exceptional conditions allowed by the Java and JVM contracts, if the function exits (whether by return or throwing), it must exit in a state in which the doubly linked list is still well formed. The splice may or may not have occurred. You may assume only one thread is executing. The reason that all conventional answers to this challenge fail is that a JVM VirtualMachineError (including an OutOfMemoryError) can be thrown between any pair of instructions. In order to succeed at goal #a, at some point one of the doubly linked list's pointers need to be updated, leaving the list ill formed. After that, a VirtualMachineError may be thrown. We might put the whole thing into a try/catch or try/finally to try to restore the list to its original state in this circumstance, but another VirtualMachineError may prevent any progress there as well. The only solution is for the function *not* to exit once the shared data structure it is to update might be in an ill-formed state. 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. In the browser context, we could perhaps force a reload. > 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. > I'm not worried about untrusted code being able to figure out what platform it's on. I do not think it useful to try to address that threat model, including for the reasons you state. > > So I don't see a use for the language to address this particular issue. > depends what issue you're worried about ;). > > David > _______________________________________________ > 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
