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

ADsafe banned list

Expand Messages
  • Douglas Crockford
    I slimmed down the ADsafe banned list. These are the names of members that may not be accessed. This list is now: arguments callee caller constructor eval
    Message 1 of 5 , May 23, 2009
    View Source
    • 0 Attachment
      I slimmed down the ADsafe banned list. These are the names of members that may not be accessed. This list is now:

      arguments callee caller constructor eval
      prototype unwatch valueOf watch

      I dropped apply and call from the list. These methods are potentially dangerous because a missing thisArg is replaced with the global object. But since ADsafe does not allow any use of this, it does not matter what this gets bound to.

      I am dropping the ADSAFE.invoke function. It is not longer needed since apply is available.
    • Douglas Crockford
      ... I do not understand the value in preventing information leaks here. What is the hazard? I am considering the blocking of try/catch in ADsafe. I am
      Message 2 of 5 , May 24, 2009
      View Source
      • 0 Attachment
        > 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 am considering the blocking of try/catch in ADsafe. I am concerned about the potential of using exceptions to deliver capabilities between isolated widgets.
      • Tyler Close
        On Sun, May 24, 2009 at 7:49 AM, Douglas Crockford ... Javascript s catch is also problematic since it enables catching of stack overflow and out of memory
        Message 3 of 5 , May 25, 2009
        View Source
        • 0 Attachment
          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 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. 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.

          Note that the widget doesn't need to guess the size of the stack, but
          can measure it at runtime before engaging in the attack.

          --Tyler

          --
          "Waterken News: Capability security on the Web"
          http://waterken.sourceforge.net/recent.html
        • Brendan Eich
          ... 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
          Message 4 of 5 , May 25, 2009
          View Source
          • 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
            up?

            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.

            /be
          • Tyler Close
            ... What about stack overflow? ... I did the testing during the caja security review and I believe I got an exploit working in both IE 6 and Firefox 2 on
            Message 5 of 5 , May 25, 2009
            View Source
            • 0 Attachment
              On Mon, May 25, 2009 at 3:37 PM, Brendan Eich <brendan@...> wrote:
              > On May 25, 2009, at 2:56 PM, Tyler Close wrote:
              >> On Sun, May 24, 2009 at 7:49 AM, Douglas Crockford
              >> > 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 about stack overflow?

              > What browsers did you test?

              I did the testing during the caja security review and I believe I got
              an exploit working in both IE 6 and Firefox 2 on Windows using the
              stack overflow Error. The stack overflow Error was easier to work with
              than the out of memory Error, since it's more predictable.

              >> 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
              > up?

              Because it wasn't expecting the function to throw. For example, the
              called function may have been one implemented in the same block of
              code as the calling function. Seeing that the called function didn't
              throw, the programmer of the victim object didn't write a try catch
              block. In general, protecting yourself against this kind of attack by
              defensively writing try catch blocks is too cumbersome and error prone
              to be feasible.

              > 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.

              Sounds like an excellent argument for making errors fail-stop. ADsafe
              is in a good position to implement this, since it can wrap all event
              handlers created by a widget.

              > 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.

              Allowing the widget to explicitly terminate the page is fine, since it
              implicitly has this authority anyways, since it could always just
              enter an infinite loop, or use other DOS techniques.

              --Tyler

              --
              "Waterken News: Capability security on the Web"
              http://waterken.sourceforge.net/recent.html
            Your message has been successfully submitted and would be delivered to recipients shortly.