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

[hawguy]

In typical PHP fashion, the patch doesn't actually fix the underlying problem, it simply checks for that one specific string. Seriously, stop gloating for 30 seconds, check the source and cringe at the incompetence.

What are you talking about? There is more than one number that triggers the problem, and the patch does not do a simple string comparison.

http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_strtod.c?r1=304407&r2=307095&pathrev=307095

Re:1 day turn-around

[Anonymous Coward]

PHP is made of 100% pure premium stupid decision.

Re:1 day turn-around

[TheRaven64]

No, PHP has features caused by stupid decisions in the past.

Re:1 day turn-around

[antdude]

But was it tested well? Does it break anything else? :P

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

[bk2204]

Actually, Microsoft's EULAs disclaim liability just like FLOSS licenses do. The difference is that Microsoft has deep pockets. Your average FLOSS project does not.

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.

Re:Why does this code even exist?

[BradleyUffner]

Localization I can almost understand. OS X is the only platform I know of that lets you specify a per-thread locale that functions like this respect. But memory allocator? It's converting a string to a double - it shouldn't need a memory allocator at all, it just scans a string and collects the digits into a mantissa and exponent then. And thread safety? It's a pure function! It doesn't need any thread safety!

each thread in windows has its own independent localization settings also.

Re:Why does this code even exist?

[localman57]

I don't think you understand how floats work. You don't "just collect them". You have to convert them into a fraction represented as a power of two. The exponent is a power of two, not a power of 10. The mantissa is the numerator of that fraction, typically with the leading 1 removed. Granted, this is something that could occur on the stack.

As for thread safety, there's a lot of math that has to happen to cacluate that fraction. On many systems, particularly embedded systems on micros without a float unit, static locations are allocated for this temporary memory, because stack accesses are often very slow on low end micros without good indexed-address instruction sets. Therefore, it is expected that the floating point libraries are not to be used reentrantly. If you launch multiple threads (or do floats at different interrupt levels) you have to save the float library static space as part of your context.

Re:Why does this code even exist?

[shutdown -p now]

Last I checked Ruby didn't have abominations such as implicit conversion of stings to numbers in operator ==.

Yes, every language and framework have some nasty bits, but some have more than others, and PHP is on the "oh fuck!" end of that spectrum.

Re:You remember the php bug you found yesterday ?

[Algorithmnast]

Please - don't you remember the last time we did that?

Oh, I guess you wouldn't.

Floating point bugs

[hhedeshian]

Sweet. PHP finally has the qualifications to enter the X86 CPU market.

Re:CmdrTaco was quote as saying

[localman57]

That is a regular expression. It searches for the word imgladiusedperl .

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:2.2250738585072011e-308

[VGPowerlord]

2.2250738585072011e-308 is a pretty specific number, is the bug just associated with this number or are there more potential floats out there waiting to be found?

It's one digit (the last one before the e; should be a 4 instead of a 1) from the minimum positive value for an IEEE-754 double precision floating-point number.

*Now* can we admit PHP sucks?

[MostAwesomeDude]

The inconsistent type system, lack of Unicode support, lack of namespaces, quirky parser, and other stupidities (== vs. ===) weren't enough, so. Is this bug inane enough to actually get people to realize that PHP bites?

Re:*Now* can we admit PHP sucks?

[LingNoi]

PHP has namespaces.

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

[wmbetts]

The OP is full of shit. It does have unicode support and does support namespaces. The generalization of the parser I have no idea what he's talking about and == vs. === makes sense if you know what you're comparing.

Re:*Now* can we admit PHP sucks?

[jjohnson]

The only reason to use PHP is if you're scripting in a shared hosting environment where PHP or Perl CGI scripts are the only options available.

If you're not, you should look at either Python or Ruby. Either will be vastly better, along with some less popular choices like Lua, Groovy, Scala, Erlang...

Basically, anything else. It's not that PHP can't be sufficient, it's that it has a long and hideously compromised development history and actually demands far more of you, the scripter, to make it safe and useful, than does any of the other scripting languages.

Re:*Now* can we admit PHP sucks?

[Just Some Guy]

PHP has namespaces.

syntax\\choices\\stupid->agree();

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

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:how does the patch work?

[adamofgreyskull]

There's a link from Rasmus' tweet to a GCC "bug" that explains the problem and potential fixes, one of which is:

(2) A partial but simple solution: Do comparisons on volatile variables only.

Hope this has been enlightening!