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

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

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

David-Sarah Hopwood

... I m not convinced that it is sufficiently robust to just check for (this === window). This should work: function robustify(aType, methodName) { var proto =

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

Douglas Crockford

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

> 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

David-Sarah Hopwood

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

Message 9 of 11
, May 21, 2008

0 Attachment

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

Douglas Crockford

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

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

David-Sarah Hopwood

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

Message 11 of 11
, May 21, 2008

0 Attachment

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

Your message has been successfully submitted and would be delivered to recipients shortly.