On Fri, Nov 4, 2011 at 12:11 PM, Claus Reinke <claus.rei...@talk21.com>wrote:
> // dynamic language
>>> Object.freeze = function(obj){return obj};
>>>
>>> You imply that this is not intended, so I can show it without spoiling
>>> the fun. I was surprised that this works.
>>>
>>
>> Since the primordials are already frozen, this assignment fails.
>>
>
> Yes. It just re-emphasizes the need to be the first to run.
> Needing to freeze "freeze" seemed a fun way to show the
> Muenchhausen aspect of getting a secure environment.
>
I haven't yet seen the movie. But since it is directed by Terry Gilliam,
it's on my list ;).
>
> I was surprised that several of my current JS environments
> do not yet implement freeze, btw. Need to watch that.
>
[...]
> Is this feature-testing something that could be emphasized more
> in SES presentations?
I haven't, but I agree with you that I should. I do emphasize that SES only
works on ES5, and that on a pre-ES5 browser, we still need the Caja
ES5-to-ES3 translator. But I should make clearer how picky initSES.js is
about what it considers and ES5 browser.
> It might be useful to remind JS coders of
> the difficulties of security - it isn't just PHP, and just because there
> are efforts like AdSafe or SES, that doesn't mean that the fight is
> won, or that solutions are easy. Highlighting the difficulties could
> avoid the I-feel-safe-because-there-are-**magic-security-black-boxes.
Although I may be understating the difficulties, I think you are
overstating them here. This problem is transient. The visible development
tip versions of all major browsers are either already SES-safe of fall
short by one bug, tested by test262, that I expect both teams to fix. This
means that shortly, the most recent released version of all major browsers
will be SES-safe. Browser makers have generally been getting more
aggressive about encouraging upgrades, so that the tail of old browsers
fades out quicker.
I'll go ahead and make a prediction that a year from now the straggler
we're all be cursing will be IE8 on Windows-XP, since I do not expect MS to
ever backport IE10 to XP, and I expect there will still be Windows users
holding onto XP for dear life.
>
>
> The second approach took longer to find but relies on non-standard
>>> features (and again, I suspect a bug/interpretation issue).
>>>
>>
>> What is your second approach?
>>
>
> Is the time up, already?-)
>
> My first approach was using store to modify array.push, also
> suggested by others. That should fail, because Array.prototype
> is frozen and freezing prevents shadowing inherited properties.
>
> In FireFox 7, it fails, but the older node-0.4.9 doesn't seem to care..
>
> My second approach was to use store to modify array.__proto__,
> adding a rogue push to a new non-frozen prototype. That should
> fail if Object.prototype is frozen, for the same shadowing reason.
>
That is very interesting. I would have expected __proto__ to be exempt from
this restriction since it isn't really a property. I'm glad to hear that it
is not exempt, at least on SpiderMonkey.
>
> In FireFox 7, it fails, but the older node-0.4.9 doesn't seem to care..
>
> To guard against, one might prevent __proto__ use in general, as
> AdSafe does, I think).
ADsafe guards against this at the price of including a full accurate JS
lexer and parser. One of my goals for SES is to see if we could get to full
ocap security without needing an accurate lexer and parser, in order to
avoid download bloat. It seems we can.
> Or ensure that array.push is the method
> one wants by not getting it from modifiable array.
>
For normal defensive SES programming use, I fear this is a bridge too far.
For programmers coming from JS, I want defensive SES to still be easy to
learn and pleasant to use.
Of course, if Alice notices the danger for this specific example, should
could reasonably use it here but not in general. But the problem is the "if
Alice notices" part. Secure programming practices only work if they defend
against most attacks without the programmer needing to have thought of
these attacks.
>
> Perhaps __proto__ should not be writeable in "use strict"?
>
That's a great idea! This never occurred to me, and I have not heard anyone
suggest this. Thanks!
>
> Perhaps test262 failures that enable security issues should be
> highlighted separately, to encourage upgrading? Or, if test262
> cannot test for non-standard features, the SES initialization
> checks could be given a similarly prominent (publicity-worthy)
> status as test262?
SES has no normative status yet in TC39, so doing so at
test262.ecmascript.org is a bit tricky. At some point I intend to bring SES
to TC39, probably on a separate track in the way i18n is separately
tracked. Once SES is on its way towards de jure standardization, then such
prominence should naturally follow. Thanks for the suggestion.
Of course, nothing stops anyone from publicizing SES in other venues, so
please feel free ;).
>
>
> Both ideas are weak, in that they could be blocked by type checks.
>>>
>>
>> How?
>>
>
> Ah, yes. I was thinking that checking the type of store's index
> parameter would prevent both of these attempts. But there is
> nothing in your spec that rules out string parameters. So, one
> would have to resort to blacklisting :-(, starting with..
>
I see. My solution, of teaching programmers to write either map.get(key) or
array[+i], is really along the same lines. Cool.
>
>> pity.. still, it was an interesting exercise.
Glad you enjoyed it.
>
>
> You also rely on you security base framework being the first to run,
>>>
>>
>> Yes, absolutely.
>>
>> and on nobody trying to modify source on load, right?
>>>
>>
>> I think the answer to this is "yes" as well, but first I should ask for
>> clarification: source to what?
>>
>
> The source being run/being "attacked". Re-directing the loader
> to rewrite the source could strip away "security" features even
> easier than overwriting non-frozen standard objects.
>
Yes.
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
