caller poison pills, revisited (Was: A few arrow function specification issues)
On Apr 23, 2012, at 10:18 AM, Brandon Benvie wrote: 6) Do arrow functions need to have per instance caller and arguments poison pill properties? I propose no, because they are a new feature. But we can include a NOTE warning against providing their non-standard legacy implementation. For simplicity and uniformity, I'd keep the same semantics as for ordinary functions. Don't special-case if there is no strong reason to do so. Can arrow functions just not have arguments, caller, and name at all? I have to say, it's really annoying having to special case these properties when trying to create function proxies that are mostly virtual, as they are non-configurable, non-writable, and own properties. It at least partially depends upon the properties of Function.prototype because if a arrow function does not implement these properties as own properties it will inherit their definitions (or lack, there of) from Function.prototype. This raises the issue that ES5.1 overlooked poisoning caller/arguments for Function.prototype. Only function object created using the algorithm in 13.2 have the the poison pill properties and Function.prototype is not specified using 13.2. I'm becoming increasing convinced that the poison pill approach to securing the caller chain is a poor approach. We keep finding leaks in and it does nothing to prevent implementation from inventing new ways to expose the stating they are trying to hide. I now think we would be better off with a general,non-algorithmic restriction on conforming implementation that forbid them from exposing elements of the caller chain in the situations that the poison pills were intended to address. I'd like MarkM or other SES advocates to propose language that expression the restriction they need. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: caller poison pills, revisited (Was: A few arrow function specification issues)
Allen Wirfs-Brock wrote:
This raises the issue that ES5.1 overlooked poisoning caller/arguments
for Function.prototype. Only function object created using the
algorithm in 13.2 have the the poison pill properties and
Function.prototype is not specified using 13.2.
Function.prototype is special already:
js Function.prototype
function () {}
js Function.prototype.prototype
js
I think we did the right thing in not adding poisoned pills to it. Was
there a capability leak involving Function.prototype that I missed?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: caller poison pills, revisited (Was: A few arrow function specification issues)
On Apr 23, 2012, at 11:15 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
This raises the issue that ES5.1 overlooked poisoning caller/arguments for
Function.prototype. Only function object created using the algorithm in
13.2 have the the poison pill properties and Function.prototype is not
specified using 13.2.
Function.prototype is special already:
js Function.prototype
function () {}
js Function.prototype.prototype
js
I think we did the right thing in not adding poisoned pills to it. Was there
a capability leak involving Function.prototype that I missed?
caller and arguments properties on functions are a non-standard extension, so
the ES spec. can really say whether or not they exist on Function.prototype
except by actually defining them. Poison pills prevent an implementation from
extending strict functions created via 13.2 from adding such own properties.
It doesn't prevent a new kind of strict function (eg, arrows) that inherit from
Function.prototype but is not specified to have poison pills (as suggested by
Brendan Benvie) from from inheriting an implementation defined caller or
arguments property.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: caller poison pills, revisited (Was: A few arrow function specification issues)
Allen Wirfs-Brock wrote: caller and arguments properties on functions are a non-standard extension, Right you are: js Function.prototype.caller null js Function.prototype.arguments null and of course this is heap not code, so strictness doesn't enter into it. Still happy to change our implementation to remove these from Function.prototype if that avoids perpetuating them and their poison pill variants via arrows. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: caller poison pills, revisited (Was: A few arrow function specification issues)
I'm becoming increasing convinced that the poison pill approach to securing the caller chain is a poor approach. We keep finding leaks in and it does nothing to prevent implementation from inventing new ways to expose the stating they are trying to hide. I now think we would be better off with a general,non-algorithmic restriction on conforming implementation that forbid them from exposing elements of the caller chain in the situations that the poison pills were intended to address. This sounds a bit drastic—wouldn't it preclude V8's Error.captureStackTrace? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: caller poison pills, revisited (Was: A few arrow function specification issues)
The threat (not sure how real) is not a string telling the backtrace, it's an object reference to an ancestor function in the call stack. /be Domenic Denicola wrote: I'm becoming increasing convinced that the poison pill approach to securing the caller chain is a poor approach. We keep finding leaks in and it does nothing to prevent implementation from inventing new ways to expose the stating they are trying to hide. I now think we would be better off with a general,non-algorithmic restriction on conforming implementation that forbid them from exposing elements of the caller chain in the situations that the poison pills were intended to address. This sounds a bit drastic—wouldn't it preclude V8's Error.captureStackTrace? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: caller poison pills, revisited (Was: A few arrow function specification issues)
On Mon, Apr 23, 2012 at 11:15 AM, Brendan Eich bren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
This raises the issue that ES5.1 overlooked poisoning caller/arguments
for Function.prototype. Only function object created using the algorithm
in 13.2 have the the poison pill properties and Function.prototype is not
specified using 13.2.
Function.prototype is special already:
js Function.prototype
function () {}
js Function.prototype.prototype
js
I think we did the right thing in not adding poisoned pills to it. Was
there a capability leak involving Function.prototype that I missed?
As allowed by the spec, yes. Fortunately, this is securable on the latest
available dev versions of IE, FF, Chrome, Safari, and Opera. For some of
these, even the released version is already securable.
From http://es-lab.googlecode.com/svn/trunk/src/ses/explicit.html on
Chrome 19.0.1084.30
beta
-
[-] 29) All fine: Built in functions leak caller.
See http://code.google.com/p/v8/issues/detail?id=1643
http://code.google.com/p/v8/issues/detail?id=1548
https://bugzilla.mozilla.org/show_bug.cgi?id=591846
http://wiki.ecmascript.org/doku.php?id=conventions:make_non-standard_properties_configurable
See Test
Sbp_A10_T1http://hg.ecmascript.org/tests/test262/file/c84161250e66/test/suite/bestPractice/Sbp_A10_T1.js
-
[-] 30) All fine: Built in functions leak arguments.
See http://code.google.com/p/v8/issues/detail?id=1643
http://code.google.com/p/v8/issues/detail?id=1548
https://bugzilla.mozilla.org/show_bug.cgi?id=591846
http://wiki.ecmascript.org/doku.php?id=conventions:make_non-standard_properties_configurable
See Test
Sbp_A10_T2http://hg.ecmascript.org/tests/test262/file/c84161250e66/test/suite/bestPractice/Sbp_A10_T2.js
visiting http://es-lab.googlecode.com/svn/trunk/src/ses/explicit.html in
your browser will state whether your browser is securable. The diagnostic
on #29 and #30 will state whether this issue in particular is securable.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: caller poison pills, revisited (Was: A few arrow function specification issues)
On Mon, Apr 23, 2012 at 11:42 AM, Brendan Eich bren...@mozilla.org wrote: The threat (not sure how real) is not a string telling the backtrace, it's an object reference to an ancestor function in the call stack. The ancestor function leak is vastly worse than the backtrace into leak, but both are real. http://code.google.com/p/es-lab/source/browse/trunk/src/ses/debug.js is SES's attempt to secure backtrace leakage on some browsers. /be Domenic Denicola wrote: I'm becoming increasing convinced that the poison pill approach to securing the caller chain is a poor approach. We keep finding leaks in and it does nothing to prevent implementation from inventing new ways to expose the stating they are trying to hide. I now think we would be better off with a general,non-algorithmic restriction on conforming implementation that forbid them from exposing elements of the caller chain in the situations that the poison pills were intended to address. This sounds a bit drastic—wouldn't it preclude V8's Error.captureStackTrace? __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
