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

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

[Anonymous Coward]

Or, the OSS software gives it to you for free, but 'as is'. So they can go "Here's a fix for it. If we break something else, we're not responsible. We may try to fix that, or you can go fix it yourself."

In Microsoft's case, if they break something down the line, they have potential lawsuits against them. They try to use EULA's to try and protect themselves, but it's not foolproof. They're dealing with real money, so they have people trying to mitigate further issues. And that usually means heavy testing, on a wide range of their operating system versions and a wide range of hardware configurations.

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

[pstorry]

Risk management.

Every change is a potential new bug. Even your security patch may bring a new security issue.

You test and you test and you test, but nothing's certain in the eyes of management. So the shipping is delayed, the testing continues, and eventually you have a batch of bugfixes and patches you're fairly certain works well together. Traditionally, you call that collection a service pack, and you ship... ;-)

(Remember the blue-screen problems a Microsoft patch caused some folks a while back? That was embarrassing. So don't kid yourself that this isn't risky.)

This is also why companies prefer to move to an established "cadence" or rhythm. Monthly security patching is Microsoft's preference, for example. IBM has some software divisions which keep to a four or six month "point release" shipping schedule. Not good enough for v9.0.2? Well, it'll probably be in v9.0.3in six month's time...

That cadence helps with testing, and reduces the risk you're taking, and therefore helps to preserve your reputation and therefore your business.

Open source projects often just ship "when it's ready", and are more open anyway. They're not thinking like a company which is trying to manage its reputation and maximise business (well, profits really).

An open source project just wants to ship something that's reliably usable and useful. That changes their motivations, and therefore changes their management of patching and shipping...

Re:1 day turn-around

[dlgeek]

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

[0123456]

He's not kidding nor exaggerating at all. If a security fix breaks $foo, then, only because Microsoft and $foo's company is in the USA, can be liable to be sued for it.

When was the last time anyone successfully sued a software company for something like that?

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

Re:1 day turn-around

[Anonymous Coward]

PHP is made of 100% pure premium stupid decision.

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.

Hmmmm

[Anonymous Coward]

Step 1: Write stuff in PHP
Step 2: ???
Step 2.9999990834239320: Profit!

Why does this code even exist?

[TheRaven64]

Maybe I'm missing something, but why does PHP have its own version of strtod()? It's a standard C99 function, so you'll find it in libc or equivalent in any C99-compliant platform (including Windows) and more effort has probably gone into optimising that version than the PHP version, although if you're converting from strings to floating point values anywhere performance critical then you're probably Doing It Wrong.

Did the Zend team think that there weren't enough security holes in PHP and decide to increase the attack surface?

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.

Infinite loop seems appropriate

[gstrickler]

I mean, for all practical purposes, it's an infinitely small number, so why shouldn't it be an infinite loop?

Very large?

[GrAfFiT]

Am I the only one to notice that 2.2250738585072011e-308 is not very large?
Apparently, some journalists need a patch too.

My 2.2250738585072011e-308 cents.

Re:*Now* can we admit PHP sucks?

[MichaelKristopeit332]

i've been saying this about intel chips for DECADES... why won't anyone listen? INTEL CHIPS SUCK! they once handled a single floating point edge case incorrectly! AND THEN THEY FIXED IT! WHY WOULD ANYONE USE AN INTEL CHIP?

ignorant hypocritical marketeering = the highest level of insight.

slashdot = stagnated.

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:*Now* can we admit PHP sucks?

[Ant P.]

"Correct" use of the language is to ignore string functions entirely and use an optional extension, because they don't actually support Unicode. In 2011. Amazing.

You know, C actually has a valid excuse for that sort of thing. But I'm sure you'd rather call people names all day like a retarded skript kiddie, than admit PHP's Unicode handling is ass-backwards and crippled compared to everything else out there.