Good advertisement in a way for more type safe languages, given I'm passing something as a string into JSON then using it as a string but PHP still converts it to a double which triggers this error.
This isn't really a bug that originates from PHP's handling of types. If any floating point variable containing this number crashes the process, it doesn't matter whether the type declaration was implicit or not. Also, since you're using JSON as an example (why?), it's worth noting that type-safe languages require some sort of mapping for JSON fields as well, any of which could be FLOAT or DOUBLE and would thus be vulnerable. Until today there was no reason to assume the floating point types weren't safe, either. Finally, it has already been pointed out that the problem is caused by a GCC optimization bug, so the implication is that any recent GCC-compiled executable may be vulnerable to erratic behavior upon encountering this number.
I was using JSON as an example because it's taking something in JSON specified as a string, using quotation marks, and automatically converting it to a double.
I wasn't referring to this being the cause, just in other languages if you pass a string through JSON it would never end up being decoded to a double, just because syntactically it is a double.
> taking something in JSON specified as a string, using quotation marks, and automatically converting it to a double.
I can't see anything wrong with this behavior. Double isn't supposed to be any less safe than any other type.
> I wasn't referring to this being the cause, just in other languages if you pass a string through JSON it would never end up being decoded to a double, just because syntactically it is a double.
I believe there is a fundamental misunderstanding here. Other languages would indeed convert to double if so instructed, or if the value presented was a (high) floating point value. And once again, I can see no inherent problem with a JSON parser that looks at a floating point number and interprets it as a double. The only problem would be the memory space of a double vs that of a float or smaller type, but since PHP doesn't make that distinction the point is moot. I don't see the evilness of it, nor do I see how static typing would avoid bugs such as this.
More generally speaking, if one of the basic types of a language is defectively handled, there is no way this bug goes away if you declare that type beforehand. It has quite simply nothing to do with it. I guess an argument could be made that less code would be vulnerable on account of having less instances of doubles around, but it would still be a huge problem. And it's not like floating point numbers are somehow rarely used.
This bug could potentially hit any language. The issue lies in the parsing of the number. The fact that php triggers that parsing implicitly is incidental. It could just as well happen in e.g. Java using an explicit Double.valueOf(vulnerableString)
