574953 - Detection method for delete operator

Status: VERIFIED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Mario Heiderich]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3

During testing with the delete operator e.g. delete alert; I started to miss a possibility to detect the deletion on a variable. According to @sirdarckcat the possibility existed once via Window.prototype.constructor - but does not work anymore.

It's quite relevant in many scenarios to be able to detect the deletion of a userland and/or native property via the delete operator. The usual __defineSetter__ and __defineGetter__ - even on Window.prototype.alert (for monitoring the deletion of alert) as well as watch() don't work. The same is of course for window.__proto__. 

Is there any plans to provide such a possibility before ES5 comes around the corner?

Reproducible: Always

Comment 1

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Sounds like JS to me. Note that ES5 is already here.

Comment 2

[Mario Heiderich]

@Ms2ger Thanks for changing the category - makes sense. By mentioning ES5 I was referring to features like Object.freeze() (http://ejohn.org/blog/ecmascript-5-objects-and-properties/). This would in the best (or worst - depending on the scenario) not provide a possibility to detect property deletion - but block it (I guess). 

Preferred would still be a way to detect it - although it would require the properties involved in detection to be "freezable" too.

Comment 3

[Andreas Gal :gal]

Take a look at proxies that we implement:

http://wiki.ecmascript.org/doku.php?id=harmony:proxies

That won't work for the global object though. The global object is special, and for performance reasons you don't want it to be a special object such as a proxy.

Comment 4

[Mario Heiderich]

@Andreas I am aware of proxies - and use __noSuchMethod__ right now. But let's create a small scenario to describe the problem:

 * benign script overwrites let's say window alert
 * evil script performs a delete alert;
 * benign script cannot react on that by detecting the deletion via __defineGetter__ et. al.
 * evil script bypasses benign script's restrictions via delete alert; or delete Window.prototype.alert

Hope that provides more clarity in what i mean.

Comment 5

[Brendan Eich [:brendan]]

Proxies are all the meta-programming standardized JS will add, because we do not propose to "climb the meta ladder" and put every object at risk of its internal methods (in the ECMA-262 spec) being hooked to user-defined functions.

Comment 4 worries about ill-defined security threats, but meta-programming hooks are a security attacker's dream. You can't special-plead that hooking a delete observer helps you defend -- what if the evil script hooks first, and hooks all observable operations?

If you are mixing evil and trusted scripts in a single "vat" (window or iframe), you need defensive consistency measures at least: Object.freeze, not delete or any mutation operator. Check out Google Caja and similar systems.

Security properties (predicates over all future program states) require pervasive mediation (reference monitor of some kind) to enforce. This is beyond the scope of scriptable meta-programming hooks. It requires compiler and VM or OS level support. We are researching the compiler/VM approach.

Beyond that, we aren't going to extend the JS standard except for Harmony-era proposals that look like they'll be in a future edition of ECMA-262.

/be

Comment 6

[Brendan Eich [:brendan]]

If you want mutation to be possible on a defensively-consistent object shared across a trust boundary, then Proxy is the way to go. You can hook delete and everything else. You just can't do this to pre-defined non-proxy objects, and it is not safe to do so.

/be

Comment 7

[Mario Heiderich]

I see - that proves my assumption :) I don't fully agree on "meta-programming
hooks are a security attacker's dream" because the lack of them are the same too - two sided sword. In terms of order of deployment in the "vat" it's a nice to have for security purposes - the good ones. An attacker would not be able (ideally of course) to break out the parent pages JS based restrictions - which can provide many benefits.

Comment 8

[Brendan Eich [:brendan]]

Mario, my point is only that without meta-programming APIs, with only base-level semantics, an attacker can do strictly less, compared to what can be done with a meta-object protocol. You're right this doesn't argue against meta-programming _per se_. It does argue for stratification: meta- and base-level separation with intercession only on a-priori-meta-programmable objects (Harmony Proxies).

To uphold security properties (remember, for-all-future-program-states), you need either invariance (freeze), pervasive mediation (proxy-based membranes, or an internal equivalent), or a combination of the two. ES5 has Object.freeze, and we now have proxies (thanks to Andreas for the implementation, Tom Van Cutsem and Mark Miller for the spec). These help a great deal.

But there's always more to do -- security is never "done". Onward! :-)

/be

Comment 9

[Mario Heiderich]

@Brendan Thanks for the info - do you have a ticket no. at hand? I tried searching from here but w/o success https://bugzilla.mozilla.org/show_bug.cgi?id=ES5

Comment 10

[Brendan Eich [:brendan]]

Hmm, bugzilla aliases are lower-case:

https://bugzilla.mozilla.org/show_bug.cgi?id=es5

/be

Comment 11

[Brendan Eich [:brendan]]

Proxies were implemented under this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=harmony:proxies

/be

Comment 12

[Mario Heiderich]

Great - thanks!