Loading ...
Sorry, an error occurred while loading the content.

300Re: [caplet] Re: ADsafe banned list

Expand Messages
  • Brendan Eich
    May 25, 2009
    • 0 Attachment
      On May 25, 2009, at 2:56 PM, Tyler Close wrote:
      > On Sun, May 24, 2009 at 7:49 AM, Douglas Crockford
      > <douglas@...> wrote:
      > >> So, I suggest that you consider adding 'stack', and possibly
      > >> 'message', 'stacktrace' and 'toSource', to the banned list.
      > >
      > > I do not understand the value in preventing information leaks here.
      > > What is the hazard?
      I'd like to know too -- you can throw an object that you could return,
      so that's not it.

      Is it the ES3 spec bug, not implemented by many browsers, where the
      scope of the catch variable is a new Object (and so can be attacked by
      Object.prototype setters or throwing a function that's called to
      capture |this|)? What browsers still do that?

      > > I am considering the blocking of try/catch in ADsafe. I am
      > concerned about the
      > > potential of using exceptions to deliver capabilities between
      > isolated widgets.
      > Javascript's catch is also problematic since it enables catching of
      > stack overflow and out of memory errors.

      Out of memory is not catchable in SpiderMonkey.

      What browsers did you test?

      > A widget could use this
      > ability to put another object, or perhaps even the browser, in an
      > inconsistent state. For example, the widget could use up all but one
      > stack frame and then make a call to a browser object which mutates
      > part of its state and then attempts a function call before making
      > additional mutations. The victim object would make the first mutation,
      > but suffer a stack overflow error before being able to complete the
      > rest of the mutations. The widget code could catch the Error, leaving
      > the victim object in the inconsistent state.

      Sounds like a bug in the victim object. Why didn't it catch and clean

      Really, there are lots of potential bugs where an inconsistent state
      could result from errors. Making the errors fatal to the currently
      exeucting script only increases consistency in that particular script
      or event handler's control flow. The next script or event can still
      the inconsistency.

      If you poison the whole well, meaning both fail-stop the script and
      make the entire reachable object graph inaccessible or error-tainted,
      then you can limit the leak. But there's still a termination channel.

    • Show all 5 messages in this topic