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 <
http://hg.ecmascript.org/tests/test262/file/c84161250e66/test/suite/ch08/8.6/8.6.2/S8.6.2_A8.js
>.

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.

-- 
    Cheers,
    --MarkM
-------------- 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