On Mar 27, 2013, at 7:53 PM, Jussi Kalliokoski <[email protected]> wrote: > > Given that we can't guarantee that the bit pattern will remain unchanged the > spec should mandate normalizing to the non-signalling NaN. > > --Oliver > > It's not trivially exploitable, at least not in SM or V8. I modified the > example Mark made [1] and ran it through js (SpiderMonkey) and node (V8) to > observe some of the differences of how they handle NaN. Neither could be > pwned using the specified method. In V8, the difference is observable only if > you assign the funny NaN directly to the array (i.e. it doesn't go through a > variable or stuff like that). In SM, the difference is more observable, i.e. > the bit pattern gets transferred even if you assign it to a variable in > between, but no observable enough to make pwning possible. Of course, feel > free to fork the gist and show me how it can be exploited. :) >
Of _course_ it's not trivially exploitable in V8, SM, or JSC - You even say that you can see the different NaNs come and go. In general we try not to ship trivially exploitable code. To my knowledge all engines convert signaling NaNs to a safe non signaling NaN on _load_. That is an absolutely unavoidable cost given the untyped backing stores that typed arrays insist on. If you were to say "signaling NaNs must be preserved" modern engines would have to essentially drop NaN boxing, and take a huge hit to general performance and memory use. The alternative would be a land of trivial exploitation - If you want to see how bad it would be you'll need to modify your engine of choice to stop it from performing NaN canonicalization on read, and then see what happens when you do stuff like doubleArray[indexOfBogusNaN].toString() As an implementer I can tell you that you'll be able to make it crash. And exploiting it would not be too much harder. --Oliver
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
