« Return to Thread: Another de-facto insecurity we need to fix in ES5
Re: Another de-facto insecurity we need to fix in ES5
by Mark S. Miller-2
::
Rate this Message:
On Wed, Jun 17, 2009 at 7:10 PM, Maciej Stachowiak <mjs@...> wrote:
The tie to ES5 is that ES5 introduces the notion of frozen objects. Together with ES5/Strict function's encapsulation being protected even from non-strict code, this enables the creation of tamper-proof objects. But only if frozen objects cannot have their [[Prototype]] property changed out from under them.
In case this experiment does run into problems, what do you think about Allen's proposed restriction: "That [[Prototype]] is guaranteed not to change on an object for which [[Extensible]] is false."? This takes care of the security issue I'm concerned about and won't break any old code.
Agreed.
+100. An exhaustive list of such features should at least be enumerated in a non-normative appendix. If they had, it wouldn't have taken us so long to catch the mutable [[Prototype]] and F.caller issues. What other such issues might we have missed?
In a closely related matter, we also need to tighten the Chapter 16 exemptions, as the presence of these exemptions precludes *any* sound reasoning about JavaScript security. However, I have no clever ideas of what such tighter language should say. Suggestions appreciated.
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
Your phrasing of the question strikes me as odd, because changing behavior of de facto extensions like this seems orthogonal to supporting a new version of the spec. If getting rid of or restricting mutable __proto__ turns out to be feasible and a good idea, then we would not tie it to implementation timeline for ES5 features.
On Jun 17, 2009, at 3:34 PM, Mark S. Miller wrote:
I suspect we'll see some de-facto stuff come out of one or two vendors who aren't active in TC39 (Apple, Google V8).
Google is quite active in TC39. Google's representatives to TC39 (including me) are now in close coordination with our v8 team. However, v8 remains committed to following WebKit. Fortunately, AFAIK, WebKit has not yet taken any stance on whether [[Prototype]] will be mutable in their ES5 implementation. Maciej?
The tie to ES5 is that ES5 introduces the notion of frozen objects. Together with ES5/Strict function's encapsulation being protected even from non-strict code, this enables the creation of tamper-proof objects. But only if frozen objects cannot have their [[Prototype]] property changed out from under them.
As to the substantive issue: mutable __proto__ is something we would prefer not to have, but we are concerned about the compatibility issues. We look forward to hearing about Mozilla's experience with changing it.
In case this experiment does run into problems, what do you think about Allen's proposed restriction: "That [[Prototype]] is guaranteed not to change on an object for which [[Extensible]] is false."? This takes care of the security issue I'm concerned about and won't break any old code.
Personally, I think leaving "distasteful" but cross-browser features like this out of the spec in the hopes that they will wither away from neglect is a poor approach. If browsers feel pressured to implement such extensions for Web compatibility then we are not doing anyone any favors by leaving them in the domain of mutual reverse-engineering. I would prefer to see such features explicitly specified (with suitable restrictions) or explicitly forbidden, and perhaps explicitly deprecate them with the plan for further limits or outright removal in future versions of the spec. But it seems too late to make big changes in this regard for ES5.
Agreed.
Maybe in the next version.
+100. An exhaustive list of such features should at least be enumerated in a non-normative appendix. If they had, it wouldn't have taken us so long to catch the mutable [[Prototype]] and F.caller issues. What other such issues might we have missed?
In a closely related matter, we also need to tighten the Chapter 16 exemptions, as the presence of these exemptions precludes *any* sound reasoning about JavaScript security. However, I have no clever ideas of what such tighter language should say. Suggestions appreciated.
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
« Return to Thread: Another de-facto insecurity we need to fix in ES5
| Free embeddable forum powered by Nabble | Forum Help |
