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?
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
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.
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?
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.
On Mon, Apr 23, 2012 at 11:15 AM, Brendan Eich <brendan at 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 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 code.google.com/p/v8/issues/detail?id=1643
code.google.com/p/v8/issues/detail?id=1548
bugzilla.mozilla.org/show_bug.cgi?id=591846
conventions:make_non-standard_properties_configurable
See Test Sbp_A10_T1hg.ecmascript.org/tests/test262/file/c84161250e66/test/suite/bestPractice/Sbp_A10_T1.js
[-] 30) All fine: Built in functions leak "arguments".
See code.google.com/p/v8/issues/detail?id=1643
code.google.com/p/v8/issues/detail?id=1548
bugzilla.mozilla.org/show_bug.cgi?id=591846
conventions:make_non-standard_properties_configurable
See Test Sbp_A10_T2hg.ecmascript.org/tests/test262/file/c84161250e66/test/suite/bestPractice/Sbp_A10_T2.js
visiting es-lab.googlecode.com/svn/trunk/src/ses/explicit.html in your browser will state whether your browser is securable. The diagnostic
[+google-caja-discuss]
On Mon, Apr 23, 2012 at 11:13 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
I'd like MarkM or other SES advocates to propose language that expression the restriction they need.
+1.
This was actually discussed at the time for ES5. We went with the poison pill approach because at the time we couldn't get agreement to make a more general prohibition normative.
On Mon, Apr 23, 2012 at 11:42 AM, Brendan Eich <brendan at 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.
code.google.com/p/es-lab/source/browse/trunk/src/ses/debug.js is SES's attempt to secure backtrace leakage on some browsers.
On Apr 23, 2012, at 10:18 AM, Brandon Benvie wrote:
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.