On Wed, Mar 27, 2013 at 9:09 PM, Brendan Eich <[email protected]> wrote: > >> 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. >> > > Agreed. > > >> 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. >> > > It's true that conservative scanning is on the outs, sometimes as a matter > of principle (David Ungar one remarked to me that he did not consider > conservative GC to be real GC). But engines do it and ECMA-262 does not rule > it out.
I agree with all of that (including Ungar's opinion :). ECMA-262 doesn't rule out other security-risky implementation choices either [1]. > What makes conservative scanning troublesome, in the present case, is the > design of weak maps as implemented in Tamarin (AS3 was the target Dion > exploited). > > My conclusion is different from yours, which I suggest is unfairly biased > against conservative GC :-). I say we need careful weak ref notification > (end-of-turn with an empty stack may be sufficient), and *no* enumeration of > weakmaps. And that last conjunct is what David was disputing. I agree we need to be careful, and I don't think we should add weak map enumeration right now. However, I think this demonstration makes a much stronger case against conservative GC. Dion's attack requires, fundamentally, three things: 1. Conservative GC (of any form). 2. Some data structure that the browser holds weakly if at all, but can be held strongly from JS. 3. Some way to tell if that data is collected. I think that there's no way to eliminate 2 & 3 from the browser. For example, 2 could be a large array, and 3 could be a `currentMemoryUse` function (which doesn't currently exist, but might). Or, 2 could be image data (which browsers may discard when you scroll away, but not if JS has a reference to the DOM node in question) and 3 could be a site that detects HTTP re-requests for those images and communicates with the attacking script by XHR. Or 2 could be any data structure that the browser memoizes creation of observably, and 3 is === on a new allocation of that structure. Now, each of these particular issues could be mitigated. And probably some of them (like the image one) are way too slow to be practical for a full address leak. But, (a) just leaking some data helps defeat techniques like ASLR, (b) learning heap locations is bad, although perhaps not as bad as stack locations, and (c) browsers are a huge surface area to eliminate this behavior from. This stuff is almost certainly not the low-hanging fruit that we'll see in the next Pwn2Own, but it's going to be next to impossible to eliminate entirely without precise collection. Sam [1] C++, for example. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
