Re: Observability of NaN distinctions — is this a concern?

Oliver Hunt oliver at apple.com
Wed Mar 27 19:14:51 PDT 2013


On Mar 27, 2013, at 7:53 PM, Jussi Kalliokoski <jussi.kalliokoski at gmail.com> 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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130328/f6510de8/attachment.html>


More information about the es-discuss mailing list