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."

1 day turn-around

[iONiUM]

The 1 day turn around for a patch is pretty impressive. I wish some bigger companies would offer such fast patches against vulnerabilities..

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:1 day turn-around

[dlgeek]

See this [joelonsoftware.com] article for some examples about the efforts Microsoft goes through in their regression testing (especially follow through the links to Raymond Chen's blog). When Microsoft has a patch, they run it through huge server farms of boxes with hundreds of thousands of different configurations and commercial software package installed, making sure none of it breaks. Their patches include all kinds of extra workarounds to ensure software that relies on undocumented interfaces continues working.

I'm as anti-microsoft as the next guy here, but the cases really aren't comparable, and you have to give them credit for their thoroughness.

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:Why does this code even exist?

[Anthracks]

Except 5.3 is the latest version, so that doesn't make sense.

Re:1 day turn-around

[tibman]

I looked. Seems they fixed it: http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_strtod.c?r1=307095&r2=307094&pathrev=307095 [php.net]

Re:how does the patch work?

[jspenguin1]

The x87 registers are all 80 bits long, while standard doubles are only 64 bits. You can get into a situation where two floating point registers contain different values that round to the same double value, yet they don't compare equal. Adding the volatile keyword forces the compiler to copy the registers to the stack and read them back every time they are accessed, truncating them to 64 bits. The patch is only needed on x86 because x86_64 uses SSE3 for floating point, which works with 64-bit floats natively.

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.

Re:*Now* can we admit PHP sucks?

[Ant P.]

PHP Warning: assert(): Assertion "strlen("£") == 1" failed in /home/ant/nou.php on line 3

Awesome Unicode support there, buddy. Performance of C combined with the user-friendliness of an interpreted high-level language! Oh wait.

Who's full of shit again?