PHP Floating Point Bug Crashes Servers

angry tapir writes "A newly unearthed bug in certain versions of the PHP scripting language could crash servers when the software is given the task of converting a large floating point number, raising the possibility that the glitch could be exploited by hackers. The bug will cause the PHP processing software to enter an infinite loop when it tries to convert the series of digits "2.2250738585072011e-308" from the string format into the floating point format. The bug only seems to affect version 5.2 and 5.3 of the language." Adds reader alphadogg: "Computer scientist Rick Regan first reported the bug on Monday, and the PHP development team issued patches the following day."

Comments

Re:1 day turn-around

[Anonymous Coward]

Two primary reasons:
1. This was a relatively trivial, extremely specific, easily reproducible bug, so fixing it was quick and low risk.
2. A major vendor like Microsoft has to do extensive testing of patches as well as give ample warning to dozens of software partners who may or may not be using some bizarre workaround for the bug or be depending on it's broken behavior. An OSS project can just put it out and let their users choose whether or not to upgrade and deal with the potential ramifications.

Note that I'm not necessarily saying one or the other is better here, it's a matter of preference and for most people it's probably situational.

Re:1 day turn-around

[I8TheWorm]

It's because they're not spending their time improving thread-safe modules, ternary operators, flip flopping again on defaulting magic_quotes, or understanding pragmatism :)

Re:Why does this code even exist?

[fishbowl]

>Maybe I'm missing something, but why does PHP have its own version of strtod()?

That's a very good question. PHP's strtod is quite complicated, has its own memory allocator, does its own localization and rounding, and it is going to some lengths to ensure its own thread safety. If I were to guess, my guess would be that some of the target platforms for PHP/Zend are deficient in these areas.

Re:1 day turn-around

[petermgreen]

On the x87 (traditional FPU for x86, still used by most code because of support for older processors) the internal temporaries are fixed size. This means if the compiler chooses to keep temporaries in FPU registers you can get marginally different results from if the compiler spills them to memory.

This has some nasty implications like doing the same comparison twice may give different results if the first comparision was done with the value still in the FPU registers and the second was done after the compiler had moved it to memory and back.

By making a variable volatile you force the compailer to store it in memory at all times and therefore ensure consistent results for comparisions involving it.