Man stelle sich folgenden Quellcode in einem Onlinebanking-Formular vor:<\/p>\n
\r\n<?php\r\nif (!empty($_POST['ueberweisungsbetrag']) && filter_var($_POST['ueberweisungsbetrag'], FILTER_VALIDATE_FLOAT)!==false)\r\n{\r\n $ueberweisungsbetrag = $_POST['ueberweisungsbetrag'];\r\n}\r\nelse\r\n{\r\n $ueberweisungsbetrag = 0;\r\n}\r\n?>\r\n<input type="text" name="ueberweisungsbetrag" value="<?php echo $ueberweisungsbetrag; ?>" \/>\r\n<\/pre>\nSieht ja eigentlich erstmal ganz vern\u00fcnftig 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<\/b> als Betrag eintippt, hat das den gleichen Effekt wie<\/p>\n\r\nwhile (true) {}\r\n<\/pre>\nN\u00e4mlich: Fatal error: Maximum execution time of 30 seconds exceeded in \/var\/www\/test.php on line 3<\/b>. Diese omin\u00f6se Zahl f\u00fchrt also PHP-intern zu einem verrecken des Scripts. Das passiert immer, wenn die Zahl auch wirklich als Zahl interpretiert wird<\/b>.<\/p>\n
Hei\u00dft:<\/p>\n
\r\nprint $_GET['floatval']; \/\/ doc.php?floatval=2.2250738585072011e-308 -> no problem - treated as string\r\nprint "2.2250738585072011e-308"; \/\/ no problem - string\r\nprint 2.2250738585072011e-308; \/\/crash!\r\nprint "2.2250738585072011e-308"*1; \/\/ crash!\r\nprint (float)"2.2250738585072011e-308"; \/\/ crash!\r\nfilter_var("2.2250738585072011e-308", FILTER_VALIDATE_FLOAT); \/\/ crash!\r\n<\/pre>\nWenn irgendwo also $_GET-Variablen validiert werden (=als Zahl interpretiert werden), k\u00f6nnte man so recht billig eine DoS-Attacke<\/b> fahren.
\nEs muss \u00fcbrigens 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<\/a> 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<\/s> 2011 – mit Dank an den Klugschei\u00dfer in den Kommentaren ;)<\/i>).\n<\/p>\nEs gibt bereits ein PHP-Bug-Ticket<\/a> dazu, gefunden hat den Bug dieser Blogger<\/a>.<\/p>\n[Update 06.01.2011]<\/h3>\n
Bei den Hacker News<\/a> gabs eine interessante Diskussion, die auch folgenden Kommentar hervorbrachte:<\/p>\n\nThis 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.\n<\/p><\/blockquote>\n
Laut Johannes Schl\u00fcter sind \u00fcbrigens auch alte PHP-Versionen bis runter zur 3.0 betroffen. F\u00fcr 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 \u00e4lteren Versionen muss mit -mfpmath=sse<\/i> bzw. -ffloat-store<\/i> PHP neu kompiliert werden. \u00dcbrigens sind laut Zend<\/a> nur die 32Bit-Versionen von Linux befallen, unter Windows jedoch 32Bit und 64Bit-Builds.<\/p>\n","protected":false},"excerpt":{"rendered":"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 … Weiterlesen