On Mar 27, 2013 6:40 PM, "Brendan Eich" <[email protected]> wrote: > > David Bruant wrote: >> >> Le 27/03/2013 15:52, Brendan Eich a écrit : >>> >>> Please read the "memory safety and weak references" thread. >>> >>> The issue is not just SES, which might remove an iterator in preparing the environment. Stock JS must not be vulnerable to jit-spray attacks due to enumerable weak maps. >> >> From what I understand of the attack, JS isn't vulnerable. Only current implementations are. I admit it carries some weight, but let's not confuse the 2. > > > No, you are misreading again. JS if it has enumerable weakmaps (you advocate) plus real-world vulns in its impls (which are *inevitable*) makes pwnage. > > Changing the disagreement to be about JS vs. its impls is off the mark. Can you re-defend enumerability of weakmaps now that I've pointed out the security risk does not apply only to SES users, to be addressed by SES removing the @iterator?
I don't think this is quite the right equation. What Dion's attack shows is that conservative stack scanning, when combined with any ability to observe GC, will leak some information about the addresses of objects. This can almost certainly be generalized to any conservative scanning. I also think that JS will inevitably need some method for GC-sensitive references, and this shows that combining these with conservative GC tech is risky. That may well be a reason to be more careful in the design of weak references, and to delay shipping them until engines improve. But I think the real lesson is that engines need to be on notice that conservative GC is a potential security risk, rather than a cost that the language has to bear forever. Fortunately, it seems that other incentives are already pushing engines toward precise GC. Sam
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
