es-discuss Digest, Vol 43, Issue 7

Leo Meyerovich lmeyerov at gmail.com
Fri Sep 3 18:04:12 PDT 2010


> Although I illustrated the non-overt channel here as a covert channel in a possibly failed attempt at clarity, my real point and my real worry is about its use as a side channel. As a side channel, this ability to sense the collection of individual objects is much more informative than anything I know of in current JS. If anyone knows of any side channels that seem as bad, perhaps I've overlooked them, so please post. If they also seem unpluggable, then I would agree that my position here becomes pointless and we'd need to give on resisting side channels as well.
> 


Off the top of my head:

1) Does ES5 fully freeze the global / root protos / etc. or allow a way to call function without them? Taint can show up through here.

2) Even with frozen APIs, do we acknowledge timing attacks? Out-of-memory, non-termination, and other platform exception tricks? 

3) Sniffing is already ubiquitous in terms of language / host API variants

Stepping back, I'm not even sure precisely why gc status classifies as a side channel. First, when passing references, defensive coders must already consider non-local properties to protect against memory leaks: gc state should, arguably,  already be carefully thought about when dealing with components. Second, this seems somewhat close to a transient resource reification pattern where it's use as explicit communication seems fine: you check against what the system has reclaimed, etc.**

Lest anyone misunderstands, I actually do agree that it's suspicious if you do not consider coding wrt to gc as being natural. Making the intended threat model to protect against more precise would help me at least. For example, it could answer why the ability to check whether an object has been collected is not an overt channel that is part of getting a reference: if you don't want somebody to check, don't give them the object.


**having overidable object destructors are probably a cleaner alternative in most cases for this second use






More information about the es-discuss mailing list