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."
Step 1: Write stuff in PHP
Step 2: ???
Step 2.9999990834239320: Profit!
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.
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?
I am TheRaven on Soylent News
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 :)
Saying Android is a family of phones is akin to saying Linux is a family of PCs.
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...
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.
PHP is made of 100% pure premium stupid decision.
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.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register