search

amohanta / google-caja

Automatically exported from code.google.com/p/google-caja
0 stars 0 forks source link

Caja code can swallow a StackOverflowError, potentially leaving the thrower in an inconsistent state #460

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?

function recurse() {
    try {
        recurse();
    } catch (e) {
        caja.log('caught stack overflow');
    }
}

Please provide any additional information below.

Any object that mutates itself, calls a method and then expects to be able
to call another method, or do another mutation, before returning can be put
into an inconsistent state by a caller that eats all but one remaining
stack frame before calling the callee. It's just too hard to program
correctly in this model.

Original issue reported on code.google.com by tyler.cl...@gmail.com on 10 Jun 2008 at 5:35

GoogleCodeExporter commented 9 years ago 
Possible fix: whitelist exceptions that do not represent nondeterministic 
failures.
When Caja code creates an exception, it is always whitelisted. The container can
explicitly create whitelisted exceptions. Any other exception causes the whole 
page
to fail.
(Possibly, it reloads the non-Javascript version of the page at that point.)

Original comment by davidsar...@googlemail.com on 10 Jun 2008 at 6:45

GoogleCodeExporter commented 9 years ago 
Similarly combination caja code being allowed to catch memory exceptions and 
long
identifiers overflowing memory means that appending __can_call___ and family to
specially crafted identifiers can abort a caja library method part way through 
and
result in caja variable in an inconsistent state.

Original comment by jas...@gmail.com on 11 Jun 2008 at 2:06

GoogleCodeExporter commented 9 years ago

Original comment by davidsar...@googlemail.com on 11 Jun 2008 at 2:55

GoogleCodeExporter commented 9 years ago 
Also, deep property accesses get translated to code that throws a "too much
recursion" error.

var a={x:1}
a.a=a;
a.a.a.a.(128 times).a.x;

Original comment by metaw...@gmail.com on 12 Jun 2008 at 9:07

GoogleCodeExporter commented 9 years ago

Original comment by erights on 15 Jun 2008 at 10:28

GoogleCodeExporter commented 9 years ago

Original comment by davidsar...@googlemail.com on 16 Jun 2008 at 6:08

GoogleCodeExporter commented 9 years ago

Original comment by mikesamuel@gmail.com on 9 Oct 2008 at 5:57

GoogleCodeExporter commented 9 years ago

Original comment by jas...@gmail.com on 2 Nov 2009 at 6:18

GoogleCodeExporter commented 9 years ago 
Since we can't do anything about this in SES, shall we close the bug?

Original comment by metaw...@gmail.com on 24 Aug 2011 at 9:28

GoogleCodeExporter commented 9 years ago 
> Since we can't do anything about this in SES, shall we close the bug?

Darn. I see your point. But this remains an open exploitable security hazard, 
so I'm inclined to leave it open as a reminder.

Original comment by erights@google.com on 24 Aug 2011 at 10:08

GoogleCodeExporter commented 9 years ago

Original comment by jas...@gmail.com on 24 Oct 2011 at 6:03

GoogleCodeExporter commented 9 years ago 
Unfortunately, my response in comment #10 remains valid, so I'm leaving this 
open as a reminder to our customers. And hopefully a prod to someone to enable 
this to be fixed in future JS and/or browser standards and implementations.

Original comment by erights on 6 Mar 2013 at 7:34

GoogleCodeExporter commented 9 years ago 
Related https://code.google.com/p/v8/issues/detail?id=214 
https://codereview.chromium.org/11362007/

Original comment by erights on 11 Mar 2013 at 4:13

GoogleCodeExporter commented 9 years ago

Original comment by erights on 11 Jul 2013 at 6:57

GoogleCodeExporter commented 9 years ago

Original comment by erights on 15 Jul 2013 at 1:57

GoogleCodeExporter commented 9 years ago

Original comment by kpreid@google.com on 7 Nov 2013 at 8:30