__proto__ security

[David Bruant]

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