Hier im Forum bekommt ihr bei euren fragen schnelle hilfe.Hier geht es rund um das Web SeitenProgrammieren.Alles rund ums Javascript,Html,Php,Css und Sql.Auf fast allen Fragen haben wir eine Antwort.
Der Soforthilfe-chat verspricht das ,was sein Name sagt. Hier sind Leute Online die sofort ihre hilfe anbieten.Seht in der OnlineListe nach und wenn einer Online ist werdet ihr auch antwort bekommen. Admine ,Moderatoren und Helfer sind unsere Spezialisten in Sachen Web Programierung
71 Unwetterwarnungen in Deutschland
Die Datenbank wurde zuletzt am 02.08.2020 17:34:28 aktualiesiert
71

fieser Bug in PHP 5.3 [Update]

Man stelle sich folgenden Quellcode in einem Onlinebanking-Formular vor:

<?php
if (!empty($_POST['ueberweisungsbetrag']) && filter_var($_POST['ueberweisungsbetrag'], FILTER_VALIDATE_FLOAT)!==false)
{
    $ueberweisungsbetrag = $_POST['ueberweisungsbetrag'];
}
else
{
    $ueberweisungsbetrag = 0;
}
?>
<input type="text" name="ueberweisungsbetrag" value="<?php echo $ueberweisungsbetrag; ?>" />

Sieht ja eigentlich erstmal ganz vernünftig aus, oder? Validierung des einigegebenen $_POST-Betrags, um dem Benutzer bei einem Fehler das erneute eintippen zu ersparen. Wenn man nun allerdings die verdammt kleine Gleitkommazahl 2.2250738585072011e-308 als Betrag eintippt, hat das den gleichen Effekt wie

while (true) {}

Nämlich: Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/test.php on line 3. Diese ominöse Zahl führt also PHP-intern zu einem verrecken des Scripts. Das passiert immer, wenn die Zahl auch wirklich als Zahl interpretiert wird.

Heißt:

print $_GET['floatval']; // doc.php?floatval=2.2250738585072011e-308 -> no problem - treated as string
print "2.2250738585072011e-308"; // no problem - string
print 2.2250738585072011e-308; //crash!
print "2.2250738585072011e-308"*1; // crash!
print (float)"2.2250738585072011e-308"; // crash!
filter_var("2.2250738585072011e-308", FILTER_VALIDATE_FLOAT); // crash!

Wenn irgendwo also $_GET-Variablen validiert werden (=als Zahl interpretiert werden), könnte man so recht billig eine DoS-Attacke fahren.
Es muss übrigens genau diese Zahl sein, bei einer minimalen Abwandlung geht alles gut. Es ist auch nur die 32 Bit Version betroffen. Bei meinen Tests unter Ubuntu (PHP Version 5.3.3-1) und Windows XAMPP (PHP Version 5.3.1) war das wunderbar reproduzierbar. Laut Golem seien die PHP-Versionen 5.3.3-6, 5.3.2-1 und 5.3.1 betroffen. Ein Update gibt es noch nicht (Stand: 04.01.2010 2011 – mit Dank an den Klugscheißer in den Kommentaren ;)).

Es gibt bereits ein PHP-Bug-Ticket dazu, gefunden hat den Bug dieser Blogger.

[Update 06.01.2011]

Bei den Hacker News gabs eine interessante Diskussion, die auch folgenden Kommentar hervorbrachte:

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.

Laut Johannes Schlüter sind übrigens auch alte PHP-Versionen bis runter zur 3.0 betroffen. Für die aktuelleren 5.3 und 5.2 Zweige wurden jeweils aktualisierte Versionen (5.3.5 bzw. 5.2.17) released, die diesen Bug beheben. Auf älteren Versionen muss mit -mfpmath=sse bzw. -ffloat-store PHP neu kompiliert werden. Übrigens sind laut Zend nur die 32Bit-Versionen von Linux befallen, unter Windows jedoch 32Bit und 64Bit-Builds.

Add Comment

* Required information
1000
Powered by Commentics

Comments (0)

No comments yet. Be the first!