PHP apps plagued by Mark of the Beast bug
Death by decimal places
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
Web developers are in a lather following the discovery of a bug in the PHP programming language that causes computers to freeze when they process certain numerical values with large numbers of decimal places.
The error in the way floating-point and double-precision numbers are handled sends 32-bit systems running Linux, Windows, and FreeBSD into an infinite loop that consumes 100 percent of their CPU's resources. Developers are still investigating, but they say the bug appears to affect versions 5.2 and 5.3 of PHP. They say it could be trivially exploited on many websites to cause them to crash by adding long numbers to certain URLs.
“Since PHP drives everything from WordPress to Wikipedia, there could be a ton of vulnerable sites,” H D Moore, CSO of Rapid7 and chief architect of the Metasploit project, told The Reg. “The use case for this would be to quickly kill any web server hosting a vulnerable PHP instance and application.”
The bug, which first came to light on the Exploring Binary blog, is triggered when PHP apps process statements such as:
<?php $d = 2.2250738585072011e-308; ?>
The crash is also triggered when the number is expressed without scientific notation, with 324 decimal places. As author Rick Regan notes, the value is the largest subnormal double-precision floating-point number. It's still not clear exactly what causes the crash, but participants on this Hacker News forum speculate it has something to do with the way 32-bit x86 processors calculate long values with a large number of decimals.
As a user named Pomax explains:
This is the nature of floating point numbers: they're not exactually [sic] "exact" at all. Converting a fixed fraction decimal number into a floating point means turning an exact number into its best approximation. In order to get the approximation as close as possible to the original number, a floating point conversion algorithm will perform several runs until the error between the original number and the floating point representation is smaller than some very small value. This leads to problems when either the error can't get smaller than the required precision, or when the error doesn't decrease per iteration. In both cases an algorithm that doesn't have error detection will be stuck in an infinite loop.
The user went on to say that the problem happens with values passed through the GET protocol, making it possible for people to trigger crashes by adding parameters to URLs that contain the number, a la “/store.php?cat=22250738585072011.”
PHP maintainers have yet to weigh in on the report. In the meantime, possible workarounds include adding a “-ffloat-store” flag to CFLAGS or stopping the execution of decimal versions of numbers that are passed as a parameter. ®
COMMENTS
Hmmmm ...
"I wonder if web devs will still try and convince the world PHP is a serious non mickey mouse language and they are real software developers."
And to think this used to be a website for people interested in and well-versed with technology.
To all you PHP haters...
I hadn't noticed any malice toward PHP until reading the comments for this article. Having since conducted a Web search for problems regarding PHP, it seems in all cases dislike for PHP stems from an inability or unwillingness to employ an effective programming methodology, as opposed to anything specifically regarding PHP.
@asdf, Thyratron, Greg: PHP is only as insecure as one's unwillingness to put some effort into the art of code design. In my experience, compiled languages lend themselves to far more buggy results than the likes of PHP. So what exactly is it that irks you lot about PHP? How is it insecure or "mickey mouse"? Get specific, for pity's sake. No one likes a hater!
Why would I find it?
I develop in PHP pretty exclusively, but since I don't ever accept input from the user without screening it, and I can't remember the last time I ever used (float) to typecast it to a float, I'm always using ints when the data should be numeric.
So according to your theory, I should have hit the bug long before now - but seeing how I've never had to write anything processing exponentials, or variables that long, it's not something I ever encountered since I made sure I turned it into a format that was safe for use *before* I used it.
Incidentally, I just tested some of the code I work with and I can't trigger this on either PHP 5.2 or 5.3... is that because I'm a bad programmer and didn't test it initially, or because I'm a good programmer and made sure I wasn't going to get invalid/nonsensical input in the first place?
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
