It doesn't appear that this is a security issue in itself, just a DOS. But before I open this up we need to know that running JS via image handlers isn't exploitable in other ways.
Status: UNCONFIRMED → NEW
Ever confirmed: true
> If the script runs in a sandbox, could we just run it in a worker? Hmm. I believe we could, yes.
Could you use sandboxed JS to create heap memory corruption? In any case, Chrome doesn't have this bug.
I'm going to open this up; it's just a DOS, which we don't typically keep hidden. I'm also going to morph the summary to mention moving this evaluation into a worker, since that would solve the DOS.
Component: Untriaged → DOM
Keywords: csec-dos, sec-low
Product: Firefox → Core
Bobby, would it be viable to create XPConnect sandbox objects on a non-main thread? I assume that we do in fact want to run this in a sandbox, not a full-up Worker, because those expose networking APIs like XHR that we don't want to expose here.
(In reply to Not doing reviews right now from comment #9) > Bobby, would it be viable to create XPConnect sandbox objects on a non-main > thread? > > I assume that we do in fact want to run this in a sandbox, not a full-up > Worker, because those expose networking APIs like XHR that we don't want to > expose here. That would involve security wrappers on workers, which is doable, but not something we'd do lightly. It seems like a quicker path to victory would just be to define a worker context with no interfaces exposed and nothing exposed by the bindings on the global. Then the worker itself is a sandbox. This might be useful for other things too.
I would like to work on this could someone help me where to start of it :)
Given bug 1018583 and its fix, I think this bug is now just invalid. We don't do the sandbox thing at all anymore.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.