PHP apps plagued by Mark of the Beast bug
Death by decimal places
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. ®