Object.prototype.* writable?

Mark S. Miller erights at google.com
Sat May 7 12:19:56 PDT 2011

On Sat, May 7, 2011 at 11:54 AM, Kyle Simpson <getify at gmail.com> wrote:

> The malicious script could schedule patching newly loaded code
>> directly without even overwriting Object.prototype (eg. to reuse your
>> example, it could replace document.location.href occurences with a
>> string constant in the 'trustworthy' function source directly).
> Not if the code in question is inside a self-executing function closure,
> which is a pretty common pattern. In that case, the only "vulnerability" to
> trusting what you see from `Object.prototype.toString` (or
> `location.href.toString`) is if it's possible that someone paved over them
> earlier, either intentionally or accidentally.
>  This means forbidding overwriting properties of Object.prototype would
>> be 'security by obscurity' at best imho.
> I already acknowledged that it's only one tiny piece of the overall "code
> security" discussion... but it would certainly help a few of those use-cases
> to be more secure.
> Maybe the more appropriate term instead of "secure" is "reliable". For
> example, the case of testing for the validity of `window.opera`... that
> special object could be more trusted/reliable (not faked or accidentally
> collided with) if it was impossible to fake the output of
> `Object.prototype.toString.call(window.opera)`.
>  On 1:44 PM, Douglas Crockford wrote:
>> I agree that the primordials should have been frozen, but as Brendan
>> says, that ship has sunk. But a smart library can now do that job, so a
>> page can elect to have the benefit of frozen primordials if it wishes.
> Again, a "smart library" can only do that if it's guaranteed to be the
> first code to run on the page. If not (which is usually the case), then all
> bets are off, unless the language offers some protections.

All bets are probably still off. The malicious code that's first can load
the latter virtuous code as data using cross-origin XHR, or, if the script
isn't served with an "Access-Control-Allow-Origin: *", via server-side
proxying. Then the malicious code can rewrite the virtuous code as it wishes
before evaling it.

I've been at this for a while, as has Crock. I doubt there's any realistic
scenario where code loaded later into an already corrupted frame can
usefully defend its integrity. If you know of a way to defend against this
rewriting attack, please explain it. Thanks.

> And "ships being sunk" not withstanding, I think it's a valid question if
> something like this could be a future candidate for a more "strict" (opt-in)
> JavaScript, like Harmony/Harmony.Next or "strict mode" itself.

We are currently prototyping such a SES (Secure EcmaScript) proposal, for
now as a smart library written in ES5. See <
http://codereview.appspot.com/4249052/> for its current in-review state.
(Although it already got one LGTM from mzero, I'm waiting on another review
before committing.) The security of this library absolutely depends on being
run before anything potentially malicious is run in the same frame.

> --Kyle
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

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

More information about the es-discuss mailing list