__proto__ security
David Bruant
bruant.d at gmail.com
Mon Feb 13 00:55:40 PST 2012
Le 12/02/2012 23:47, Brendan Eich a écrit :
> Oliver Hunt wrote:
>> On Feb 12, 2012, at 11:28 AM, Brendan Eich wrote:
>>> Heh, I knew that was coming. I'll amend to say "of long standing"
>>> after "implementations" :-P.
>>>
>>> I still have a gut feeling that someone is going to take advantage
>>> of the setter for bad purposes that will be harder to block than
>>> would be the case if __proto__ reflected as a data property. But I
>>> can't prove this.
>>
>> I'm not sure about this
>
> Likewise, as noted -- I'm not sure but my gut is unhappy :-P
The case where you have to protect against someone who kept a reference
to the setter is when you haven't deleted the property at the beginning
(assuming you have a way to run first in the environment)
Within one "vat", if you forgot, you're screwed, but you know it is easy
to fix (in your code, not necessarily the consequence on the attacked code).
An issue arise when other __proto__ setters pop up without you
necessarily knowing. And as far as I know, the only way it can happen is
when there are several frames within the same vat. So the cross-frame
check (or the stricter version based on Object.prototype) takes care of it.
But first thing, just delete Object.prototype.__proto__ anytime you
don't need it. Knowing this makes my guts feel far better than with the
current situation where, in Firefox, for instance, it is not possible to
get rid of Object.prototype.__proto__:
-----
var o = {a:1}, o2 = {a:2};
var o3 = {b:3};
o3.__proto__ = o;
console.log(o3.a); // 1
delete Object.prototype.__proto__
o3.__proto__ = o2;
console.log(o3.a); // should be 1 if __proto__ was deletable, but is
currently 2 in Firefox Web Console
-----
>> If you pull the setter function off of the prototype you can still
>> only apply it to objects you could already access.
>
> The concern (no trolling here) is at least about attack surface. If
> there's no setter that can be extracted, there's no need for the
> "frame check" (however phrased). Adding that check adds more machinery
> to get wrong or have interact in unexpected ways with other moving parts.
I'm not sure what you've described is directly a concern of attack
surface. I think it's rather a concern of "potential bugs surface"
(which can indirectly lead to security issues) and I agree that it's a
valid concern. However, the version where the check is based on the
Object.prototype identity sounds it could be written quite safely in a
couple of lines of JS, no ?
David
More information about the es-discuss
mailing list