Registration: Workshop registration will only be available at the 2008 IEEE Symposium on Security and Privacy and 2008 IEEE Symposium on Security and Privacy conference web site, but not on the day of the workshop.

2008 workshop web site:         http://seclab.cs.rice.edu/w2sp/2008/
2007 workshop web site:         http://seclab.cs.rice.edu/w2sp/2007/

-------- Original Message --------
To: Douglas Crockford <douglas@...>
Subject: ADsafe attack
From: David-Sarah Hopwood <david.hopwood@...>

(function () {
      var concat = [].concat;
      var array = concat();
      var global = ADSAFE.get(array, 0);
      global.alert('hi');
})();

This passes ADsafe and alerts on Firefox 2.0.0.14. IE seems to be more
picky about calling built-in methods on objects of the wrong type;
'concat()' throws a TypeError on IE (but I don't know whether the same
issue is exploitable some other way).

I think the problem starts with allowing the '[].concat': since methods of
the built-in types refer to 'this', it's possible for the global object to
leak from such a method when it is called as a plain function.

I don't know how to fix it while still allowing property accesses using
'.', short of blacklisting all property names that correspond to methods
of built-in types. That would be very ugly and error-prone, since you'd
have to know about any non-standard methods.

I'll wait for your response before making this public. It is also relevant
to Jacaranda, so I'd like to discuss it at the Friday meeting with MarkM
et al.

--
David-Sarah Hopwood

-------- Original Message --------
From: Douglas Crockford <douglas@...>
To: David-Sarah Hopwood <david.hopwood@...>,  Mark
Miller <erights@...>
Subject: Re: ADsafe attack

David-Sarah Hopwood wrote:
> (function () {
>     var concat = [].concat;
>     var array = concat();
>     var global = ADSAFE.get(array, 0);
>     global.alert('hi');
> })();
>
> This passes ADsafe and alerts on Firefox 2.0.0.14. IE seems to be more
> picky about calling built-in methods on objects of the wrong type;
> 'concat()' throws a TypeError on IE (but I don't know whether the same
> issue is exploitable some other way).
>
> I think the problem starts with allowing the '[].concat': since methods of
> the built-in types refer to 'this', it's possible for the global object to
> leak from such a method when it is called as a plain function.
>
> I don't know how to fix it while still allowing property accesses using
> '.', short of blacklisting all property names that correspond to methods
> of built-in types. That would be very ugly and error-prone, since you'd
> have to know about any non-standard methods.
>
> I'll wait for your response before making this public. It is also relevant
> to Jacaranda, so I'd like to discuss it at the Friday meeting with MarkM
> et al.

That is distressing. It appears to be safe on Opera, Safari, and IE, but
ADsafe surely fails on Firefox.

I don't trust a blacklist approach to guard dot, so that would mean
outlawing dot except in a few specific cases, which would make use of the
language close to unbearable.

So instead, I will fix Firefox:

Array.prototype.concat = function () {
      var concat = Array.prototype.concat;
      return function () {
          if (this === window) {
              throw {
                  name: "ADsafe",
                  message: "ADsafe violation."
              };
          }
          return concat.apply(this, arguments);
      };
}();

We will have to do this for all of the Array methods that return this. It is
galling, but I don't see a better alternative.

I think we should also add language to ES3.1 15.4.4.4 and elsewhere that
force the methods to throw when they are called as functions (with this ===
window).

Go ahead and make it public.

[This might be a duplicate; I'm having trouble posting to this list
from my usual account.]

-------- Original Message --------
From: David-Sarah Hopwood <david.hopwood@...>
To: Douglas Crockford <douglas@...>
Subject: Re: ADsafe attack

Douglas Crockford wrote:
> I don't trust a blacklist approach to guard dot, so that would mean
outlawing dot except in a few specific cases, which would make use of
the language close to unbearable.
>
> So instead, I will fix Firefox:
>
> Array.prototype.concat = function () {
>     var concat = Array.prototype.concat;
>     return function () {
>         if (this === window) {
>             throw {
>                 name: "ADsafe",
>                 message: "ADsafe violation."
>             };
>         }
>         return concat.apply(this, arguments);
>     };
> }();
>
> We will have to do this for all of the Array methods that return
this.

Not just Array; all of the methods accessible in the public API. The
problem with that approach is that there may be methods that are not
standardized, and that are also not enumerable.

If there were a way to enumerate all properties of an object
regardless
of DontEnum attributes, then it would be possible to perform this fix
automatically and reliably. Otherwise, it doesn't seem to be possible
(without rewriting) to allow unrestricted use of both '.' and '()'.

> It is galling, but I don't see a better alternative.

Jacaranda doesn't allow unrestricted use of '.'; it allows only
"foo.method(...)", "this.property", and "foo.$get('property')".
It's possible to do a 'lightweight' rewriting of "foo.property" to
"foo.$get('property')", where the rewriter is not in the TCB.

> I think we should also add language to ES3.1 15.4.4.4 and elsewhere
that force the methods to throw when they are called as functions
(with this === window).
>
> Go ahead and make it public.

OK -- can I also forward this conversation?
[The answer was yes.]

--
David-Sarah Hopwood

-------- Original Message --------
From: Douglas Crockford <douglas@...>
To: David-Sarah Hopwood <david.hopwood@...>,
Mark Miller <erights@...>
Subject: Re: ADsafe attack

I found three of Firefox's Array methods return window when called as
functions.
ADSAFE is now wrapping them:

      var mozilla = function (name) {
          var method = Array.prototype[name];
          Array.prototype[name] = function () {
              if (this === window) {
                  error();
              }
              return method.apply(this, arguments);
          };
      };

      mozilla('concat');
      mozilla('reverse');
      mozilla('sort');

I am worried about the extra Array methods (map, reduce, et al) but I
haven't found a hole yet.

-------- Original Message --------
From: Douglas Crockford <douglas@...>
To: David-Sarah Hopwood <david.hopwood@...>
Subject: Re: ADsafe attack

David-Sarah Hopwood wrote:
> Not just Array; all of the methods accessible in the public API. The
> problem with that approach is that there may be methods that are not
> standardized, and that are also not enumerable.

The public API is the stuff that ADsafe allows. The ADSAFE object may
not
contain any method that can leak. The ADsafe contract does not allow
adding
methods to the public objects that can leak. ADsafe does not allow
the public
objects to be used as values, so

      var o = Object;
      for (name in o) {

is not allowed.

It also includes anything that Firefox provides that ADsafe does not
block. Does it have any more tricks?

Douglas Crockford wrote:
> I don't trust a blacklist approach to guard dot, so that would mean
> outlawing dot except in a few specific cases, which would make use of
> the language close to unbearable.
>
> So instead, I will fix Firefox:
>
> Array.prototype.concat = function () {
>     var concat = Array.prototype.concat;
>     return function () {
>         if (this === window) {
>             throw {
>                 name: "ADsafe",
>                 message: "ADsafe violation."
>             };
>         }
>         return concat.apply(this, arguments);
>     };
> }();

I'm not convinced that it is sufficiently robust to just check for
(this === window). This should work:

    function robustify(aType, methodName) {
        var proto = aType.prototype;
        var oldMethod = proto[methodName];

        if ({}.__proto__ !== undefined) {
            aType.prototype[methodName] = function () {
                if (this.__proto__ !== proto) {
                    throw {name: "ADsafe", message: "ADsafe violation."};
                }
                return oldMethod.apply(this, arguments);
            };
        } else {
            proto._type___ = proto;
            if (Object.dontEnum !== undefined) {
                Object.dontEnum(proto, '_type___');
            }
            aType.prototype[methodName] = function () {
                if (this._type___ !== proto) {
                    throw {name: "ADsafe", message: "ADsafe violation."};
                }
                return oldMethod.apply(this, arguments);
            };
        }
    }

    robustify(Array, 'concat');

However, without having a way to enumerate all of the functions,
including undocumented ones, defined on the prototypes of
{Object,Function,Array,String,Boolean,Number,Math,Date,RegExp,*Error},
you still risk missing one that could potentially leak 'this'.

Any chance of an Object.__allKeys__(object) method, which ignores
DontEnum, in ES3.1?

--
David-Sarah Hopwood

--- In caplet@yahoogroups.com, David-Sarah Hopwood <david.hopwood@...>
wrote:
> Any chance of an Object.__allKeys__(object) method, which ignores
> DontEnum, in ES3.1?

We are considering an Object.keys method, but it will only return the
own, enumerable property names.

--- In caplet@yahoogroups.com, David-Sarah Hopwood <david.hopwood@...>
wrote:
> I'm not convinced that it is sufficiently robust to just check for
> (this === window).

Why? The test is intended to reject invocations of the method as a
function. What cases are missed?

On Wed, May 21, 2008 at 12:02 PM, David-Sarah Hopwood
<david.hopwood@...> wrote:
> Any chance of an Object.__allKeys__(object) method, which ignores
> DontEnum, in ES3.1?

Yes! The about-to-be-specified Object.getProperties(obj) will provide
a reflective description of all an object's own properties. This
operation itself will not be visible from Caja, and I wouldn't
recommend that it be visible from ADsafe, but in both cases it's
useful within the runtime libraries of these secure subsets, to help
enforce useful properties, as you explain.


--
     Cheers,
     --MarkM

Mark S. Miller wrote:
> On Wed, May 21, 2008 at 12:02 PM, David-Sarah Hopwood
> <david.hopwood@...> wrote:
>> Any chance of an Object.__allKeys__(object) method, which ignores
>> DontEnum, in ES3.1?
>
> Yes! The about-to-be-specified Object.getProperties(obj) will provide
> a reflective description of all an object's own properties. This
> operation itself will not be visible from Caja, and I wouldn't
> recommend that it be visible from ADsafe, but in both cases it's
> useful within the runtime libraries of these secure subsets, to help
> enforce useful properties, as you explain.

That's why I suggested a name using the __...__ convention.

Otherwise, a subset language that does not do rewriting must do one of:
   - blacklist the name 'getProperties', which is ugly;
   - rebind 'Object' when running subset code, which does not have
     well-defined semantics and may cause compatibility problems;
   - block access to 'Object', which would not otherwise be necessary.

Actually, a better idea would be to move *all* of the methods proposed
to be added to Object, to a new global 'Reflect'. Rebinding 'Reflect'
in order to provide tamed versions of these operations when running
subset code would not have the same problems as rebinding 'Object',
since 'Reflect' is not used for anything else.

--
David-Sarah Hopwood

--- In caplet@yahoogroups.com, David-Sarah Hopwood <david.hopwood@...>
wrote:
> That's why I suggested a name using the __...__ convention.
>
> Otherwise, a subset language that does not do rewriting must do one of:
>   - blacklist the name 'getProperties', which is ugly;
>   - rebind 'Object' when running subset code, which does not have
>     well-defined semantics and may cause compatibility problems;
>   - block access to 'Object', which would not otherwise be necessary.
>
> Actually, a better idea would be to move *all* of the methods proposed
> to be added to Object, to a new global 'Reflect'. Rebinding 'Reflect'
> in order to provide tamed versions of these operations when running
> subset code would not have the same problems as rebinding 'Object',
> since 'Reflect' is not used for anything else.

Mark came up with a better idea: ADsafe denies any access to Object.

Douglas Crockford wrote:
> --- In caplet@yahoogroups.com, David-Sarah Hopwood <david.hopwood@...>
> wrote:
>> That's why I suggested a name using the __...__ convention.
>>
>> Otherwise, a subset language that does not do rewriting must do one of:
>>   - blacklist the name 'getProperties', which is ugly;
>>   - rebind 'Object' when running subset code, which does not have
>>     well-defined semantics and may cause compatibility problems;
>>   - block access to 'Object', which would not otherwise be necessary.
>>
>> Actually, a better idea would be to move *all* of the methods proposed
>> to be added to Object, to a new global 'Reflect'. Rebinding 'Reflect'
>> in order to provide tamed versions of these operations when running
>> subset code would not have the same problems as rebinding 'Object',
>> since 'Reflect' is not used for anything else.
>
> Mark came up with a better idea: ADsafe denies any access to Object.

I don't want to have to do that in Jacaranda (where it would otherwise
be safe to allow first-class access to Object).

--
David-Sarah Hopwood

ADsafe will block the bind method. The bind method proposed for ES3.1
is safe, but the bind methods provided by the current Ajax libraries
are not because they can bind to the global object. Since ADsafe does
not allow the definition of methods that use this, little is lost by
blocking bind.

Douglas Crockford wrote:
> ADsafe will block the bind method. The bind method proposed for ES3.1
> is safe, but the bind methods provided by the current Ajax libraries
> are not because they can bind to the global object.

Don't some of these libraries have other aliases for bind-like methods?
For example Prototype has 'bindAsEventListener', although I don't know of
any specific attack based on that in the context of ADsafe.

--
David-Sarah Hopwood

David-Sarah Hopwood wrote:
> Douglas Crockford wrote:
>> ADsafe will block the bind method. The bind method proposed for ES3.1
>> is safe, but the bind methods provided by the current Ajax libraries
>> are not because they can bind to the global object.
>
> Don't some of these libraries have other aliases for bind-like methods?
> For example Prototype has 'bindAsEventListener', although I don't know of
> any specific attack based on that in the context of ADsafe.

While I remember, I think you also need to blacklist 'stack'.

<http://code.google.com/p/google-caja/wiki/ErrorExposesParameterValues>

--
David-Sarah Hopwood

ADsafe now allows long dot expressions that refine the allowed global
variables. So

     ADSAFE.koda.bosanda.bosoya.tikki.ottobo();

is now acceptable.

JSLint's UI now allows the specification of allowed global variables.
The names can be entered into a field, separated with commas. It is
recommended that the names be in all upper caps to distinguish them
from constructors and ordinary variables.

I relaxed some of the restrictions on the get method. It still
requires that the object is in fact an object (and not a function),
but it allows the returning of any value, including inherited values
and functions. The name must be a number or a string not starting with
_ and not on the banned list, which is currently

apply, arguments, call, callee, caller, constructor, eval, prototype,
unwatch, valueOf, watch

http://ADsafe.org/ now describes three methods that provide the
linkage between the guest code and the ADsafe runtime.

The first edition of adsafe.js is available at
http://adsafe.org/adsafe.js. It still lacks dom wrappage and
interwidget communication.

On Tue, Jun 3, 2008 at 1:40 PM, Douglas Crockford <douglas@...> wrote:
> The first edition of adsafe.js is available at
> http://adsafe.org/adsafe.js. It still lacks dom wrappage and
> interwidget communication.

Attached is a rough first draft of a safe DOM wrapper.  The main idea
is that untrusted script views DOM nodes simply as integer handles.
To read or mutate the DOM, the untrusted code passes the appropriate
handles to the SafeDOM API, which interacts with the real DOM.  The
SafeDOM library is intended to limit the untrusted code to interacting
only with the portion of the document tree that descends from
root_node.  Also, element creation and modification can be controlled
by a policy, as demonstrated by the implementation of createElement.

The attached code is completely untested.  It is intended to sketch
out an architecture for how the DOM API could be safely exposed to
JavaScript which passes the ADsafe validator.

Adam

Adam Barth wrote:
> On Tue, Jun 3, 2008 at 1:40 PM, Douglas Crockford <douglas@...>
wrote:
>> The first edition of adsafe.js is available at
>> http://adsafe.org/adsafe.js. It still lacks dom wrappage and
>> interwidget communication.
>
> Attached is a rough first draft of a safe DOM wrapper.  The main idea
> is that untrusted script views DOM nodes simply as integer handles.

It would be easy to make the handles opaque:

    var nodes = [];

    function handleToNode(handle) {
      return handle.__node__;
    }

    function nodeToHandle(node) {
      if (!node) return null;

      // Check if we've seen this node before.
      var handle = node.__safe_dom_handle__;
      if (handleToNode(handle) === node)
        return handle;

      // Need to allocate a new handle and add it to the nodes array.
      nodes[nodes.length] = node;
      var handle = makeHandle(node);
      node.__safe_dom_handle__ = handle;
      return handle;
    }

    function makeHandle(node) {
      return {__node__: node};
    }

    function assertHandle(handle) {
      if (handle.__node__ !== void 0)
        throw INVALID_HANDLE_ERR;
    }

[...]
    API.getElementById = function(id) {
      assertString(id);

      var n = nodes.length;
      for (var i = 0; i < n; ++i) {
        var node = nodes[i];
        if (node.getAttribute && node.getAttribute('id') === id)
          return node.__safe_dom_handle__;
      }
      return null;
    };

This approach prevents a script from relying on the fact that you're
implementing handles as integers. More importantly, though, it allows
the handle objects to implement tamed DOM methods (using lexical
encapsulation), allowing the API to look more like the original DOM:

    function makeHandle(node) {
      return {
        __node__: node,
        hasChildNodes: function () {
          return node.hasChildNodes();
        },
        getNodeType: function () {
          return node.nodeType;
        },
        getNodeName: function () {
          return node.nodeName;
        },
        getNodeValue: function () {
          return node.nodeValue;
        },
        getFirstChild: function () {
          return nodeToHandle(node.firstChild);
        },
        getLastChild: function () {
          return nodeToHandle(node.lastChild);
        },
        getNextSibling: function () {
          if (node === root_node) return null;
          return nodeToHandle(node.nextSibling);
        },
        getPreviousSibling: function () {
          if (node === root_node) return null;
          return nodeToHandle(node.parentNode);
        }
      };
    }

(It's also possible to support properties like 'nodeValue' directly rather
than via getter methods, but in that case mutable properties would have to
be kept in sync whenever the underlying node changed -- unless you rely on
Mozilla or ES3.1 property getters.)

Note that, unlike in Caja or Jacaranda, these methods cannot refer to
'this', because ADsafe does not prevent obtaining a property that holds
a function and then calling it with 'this' bound to the global object.
ADsafe also does not prevent setting arbitrary properties (unless they
start with _ or are blacklisted), so there is no encapsulation between
objects created by a given script, including handle objects. However,
encapsulation is not strictly needed for ADsafe's threat model.
Caja, Cajita and Jacaranda incur much greater implementation complexity
(less so for Jacaranda, but still more than ADsafe) in order to support
this encapsulation.

--
David-Sarah Hopwood

David-Sarah Hopwood wrote:
> Note that, unlike in Caja or Jacaranda, these methods cannot refer to
> 'this', because ADsafe does not prevent obtaining a property that holds
> a function and then calling it with 'this' bound to the global object.
> ADsafe also does not prevent setting arbitrary properties (unless they
> start with _ or are blacklisted), so there is no encapsulation between
> objects created by a given script, including handle objects. However,
> encapsulation is not strictly needed for ADsafe's threat model.

I was slightly unclear here. Encapsulation of the underlying DOM node
objects from the script is required; in the implementation I suggested,
that is achieved by a combination of holding the node in a property that
starts with _, and lexical closures. Encapsulation of other properties
of the handle objects from the script is not required: it does not matter
that a script can replace methods of a handle object, for example.

--
David-Sarah Hopwood

David-Sarah Hopwood wrote:
> Adam Barth wrote:
>> On Tue, Jun 3, 2008 at 1:40 PM, Douglas Crockford
>> <douglas@...> wrote:
>>> The first edition of adsafe.js is available at
>>> http://adsafe.org/adsafe.js. It still lacks dom wrappage and
>>> interwidget communication.
>>
>> Attached is a rough first draft of a safe DOM wrapper.  The main idea
>> is that untrusted script views DOM nodes simply as integer handles.
>
> It would be easy to make the handles opaque:
>
[...]
>     node.__safe_dom_handle__ = handle;
[...]
>   function makeHandle(node) {
>     return {__node__: node};
>   }

This will leak memory on IE (even after the nodes array has become
unreferenced after leaving the page), because JScript's excuse for a
garbage collector cannot collect cycles that involve a DOM object.
That problem could be fixed by having the node object store the index
of the handle in the nodes array, rather than a reference to the handle.

--
David-Sarah Hopwood

----- Original Message -----

From: Kris Zyp

To: dojo dev.

Sent: Monday, April 21, 2008 10:58 AM

Subject: dojox.secure

I have been working on experimental project to create a mechanism for securely running untrusted scripts with Dojo. This project uses ADsafe-like object-capability limiting in combination with a DOM facade. The idea is that an untrusted script can executed, but it will only have access to that part of the DOM (and it's descendants) that you provide it, and it won't be able to access the window object or other sensitive global objects (like cookies). Anyway, I presume that I don't have an airtight implementation yet, but I would love to have some help in trying to find holes in this security model, to see if this is going to work. I have created a test page, where you can enter a script and execute it and interact with the DOM, and see if you can access anything outside the provided sandbox:

http://persevere.sitepen.com/jsclient/dojo/dojox/secure/tests/load.html

This system does create limitations (several are noted on the page) on what you can do in JavaScript and with the DOM.

 

This would be used in combination with some type of secure loading mechanism (proxy, cross-site XHR, XDR, postMessage, etc.), to load a script in text form, and then the secure loader would execute it. I think this may have some real potential, we could provide a means for untrusted widgets and ads to be securely loaded such that they couldn't mess with main page.

 

Thanks,

Kris

I am developing an Ajax library for ADsafe. It applies a capability
discipline to the dom tree, blocking access to parents and siblings.

It wraps collections of dom nodes in lightweight 'bunch' objects that
can act on all of the nodes they hold. It is my hope that the utility
of the package will offset the inconvenience and inefficiency of
intermediation.

http://adsafe.org/dom.html

I created a safe option in JSLint for checking the safe subset. The
adsafe option assumes the safe option, and additionally checks for
ADsafe widget conventions.

On Fri, Jun 27, 2008 at 1:44 AM, Mario Heiderich
<Mario.Heiderich@...> wrote:
>
> http://peter.michaux.ca/article/8069
>
> Just in case this is not known/intercepted yet.

Wow. No, we had no idea. I admit that I am shocked that the one tight
encapsulation mechanism in JavaScript itself -- lexical closures --
has now been ruined. Fortunately, all safe JavaScript subsets (Caja,
Cajita, ADsafe, FBJS, Jacaranda) already prevent access to the eval
function, as they must. So we should all be safe from this particular
new hole. However, so long as browser vendors feel free to quietly
introduce holes this large in existing functions...


--
     Cheers,
     --MarkM

On Fri, Jun 27, 2008 at 12:39 PM, Brendan Eich <brendan@...> wrote:
> There's no "now" -- this old eval extension was added over ten years ago:
>
>
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/js/src/jsobj.c&rev=3.2&mark\
=580-590

Hi Brendan, I was completely unaware of this history and did indeed
think that this was a newly opened hole. I'm very pleased to find that
it isn't. I'm especially pleased to hear that you folks plan to remove
this in a future release. Thanks for the clarification!


--
     Cheers,
     --MarkM