Weak event listener
samth at ccs.neu.edu
Wed Mar 27 15:54:48 PDT 2013
On Mar 27, 2013 6:40 PM, "Brendan Eich" <brendan at mozilla.com> 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
> No, you are misreading again. JS if it has enumerable weakmaps (you
advocate) plus real-world vulns in its impls (which are *inevitable*) makes
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss