Lecture series on SES and capability-based security by Mark Miller

Mark S. Miller erights at google.com
Fri Nov 4 19:04:04 PDT 2011

On Fri, Nov 4, 2011 at 11:46 AM, David Herman <dherman at mozilla.com> wrote:

> This is the only one I've seen that seems like it should work, but it
> depends on whether SES/Caja/etc have some sort of way of neutering
> __proto__. Just from hacking around, I don't see much way of censoring it
> in SpiderMonkey.
> MarkM, do you have any tricks for censoring __proto__?

Not censoring, no. However, for code that follows the following best
practices, uncensored __proto__ should be harmless.

1) Avoid objects as maps -- use Maps as maps.
2) Always use array[+i] for numeric indexing. Note that this can still
access properties named 'NaN', 'Infinity', and '-Infinity'.
3) Always freeze, or at least seal, objects potentially exposed directly to
untrusted clients.

#3 is crucial, and works because ES5.1 section 8.6.2 says:
"if [[Extensible]] is false the value of the [[Class]] and [[Prototype]]
internal properties of the object may not be modified. Once the value of an
[[Extensible]] internal property has been set to false it may not be
subsequently changed to true."

This is tested by test262 at <

The visible development tip of all major browsers except Opera 12 alpha
build 1116 already implement this restriction. initSES.js considers that
Opera unsafe for this reason.

Nevertheless, if I could cheaply censor __proto__ I would. Since I'm not, I
am *very* curious is this leaves open other attacks against code obeying
the above best practices. If any of you see some other avenue of attack,
*please* let me know. Thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111104/02200012/attachment.html>

More information about the es-discuss mailing list