В интерпретаторе PHP версий 5.2 и 5.3 была обнаружена (http://www.exploringbinary.com/php-hangs-on-numeric-value-2-.../) довольно странная ошибка: при обработке некоторых числовых значений (в частности, 2.2250738585072011e-308) интерпретатор зависал (достаточно выполнить "$a = 2.2250738585072011e-308;" или "$a = '2.2250738585072011e-308'; echo $a + 0;").Как показали дальнейшие исследования (http://news.ycombinator.com/item?id=2066352), такое поведение интерпретатора вызвано наличием ошибки округления, порождающей бесконечный цикл при попытке преобразования строки в число. Что характерно, сходные аномалии при операциях с вещественными значениями были замечены (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323) при работе с gcc еще в 2000 году. Однако, стоит подчеркнуть, что корень ошибки кроется не в конкретной реализации компилятора, а в некорректной (http://gcc.gnu.org/ml/gcc/2003-08/msg01195.html) работе процессоров архитектуры x86 с вещественными 64-битными т...
URL: http://www.theregister.co.uk/2011/01/04/weird_php_dos_vuln/
Новость: http://www.opennet.me/opennews/art.shtml?num=29203
Чего бы такого поломать...Кстати, что-то я не понял, обычно же процессы php рождаются и умирают, и что даст смерть процесса?
Сейчас проверил на lighttpd+cgi и apache+mod_php5, в обоих случаях только выполнение скрипта зависало, а сам сервер как работал, так и продолжает работать, как и раньше.
> Кстати, что-то я не понял, обычно же процессы php рождаются и умирают,
> и что даст смерть процесса?представьте себе что подобную ситуацию генерирует внешний злоумышленник,
много раз, в это время php будет кушать процессор, пока не умрет по max_execution_timeбесполезный расход ресурсов вообщем, если сервер с маленькими ресурсами, то ему несколько таких запросов одновременно может и хватить чтобы он перестал обслуживать остальных
>> Кстати, что-то я не понял, обычно же процессы php рождаются и умирают,
>> и что даст смерть процесса?
> представьте себе что подобную ситуацию генерирует внешний злоумышленник,И как же ему это сделать интересно :) ?
Чтобы какую-то "вредоносную строку" обработал движок PHP целевой системы - нужно сначала залить на целевую систему файл dos.php (что просто так тоже не сделать) и потом уже движком сайта попытаться его открыть ?
типа http://target.ru/dos.php ? или можно через адресную строку браузера передать "вредоносную строку" ?
<?php
if($_GET("A")) $a=doubleval($_GET(A));
?>На форумах и блогах такое увидишь не часто... Но на сайтах других типов (а-ля office online).
> И как же ему это сделать интересно :) ?
> Чтобы какую-то "вредоносную строку" обработал движок PHP целевой системы - нужно сначала
> залить на целевую систему файл dos.php (что просто так тоже не
> сделать) и потом уже движком сайта попытаться его открыть ?
> типа http://target.ru/dos.php ? или можно через адресную строку браузера передать "вредоносную
> строку" ?какой наивный...
а -mfpmath=sse никак они комментируют на x86 ? по сути получается то же, что и на amd64
<?php
$a = '2.2250738585072011e-308';
echo $a + 0;
?>
проверила у себя на сервере, ничего не зависло, php 5.3.4 собрана с -march=core2 -mfpmath=sse -mssse3
аналогично
filosofem@ivan-01:~$ php -a
Interactive shellphp > $a = 2.2250738585072011e-308;
php > echo $a + 0;
2.2250738585072E-308
php > ^Dfilosofem@ivan-01:~$ php -v
PHP 5.3.3-1ubuntu9.1 with Suhosin-Patch (cli) (built: Oct 15 2010 14:00:18)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend TechnologiesНужна статистика какие версии и как запущены. Уязвимы я полагаю конкретно какие-то версии модуля апача.
по версиям как раз написано, что уязвимы все 5.2 и 5.3, втч и 5.3.4
в вашем случае интересно влияние сухосина на уязвимость )
> по версиям как раз написано, что уязвимы все 5.2 и 5.3, втч
> и 5.3.4
> в вашем случае интересно влияние сухосина на уязвимость )Еще интересно влияние как запущен PHP, как модуль, или как CGI.
Zend/zend_strtod.cпатч на этот файл, zend engine собирается одинаково в любом случае, что cli, что cgi, что mod_php , что php-fpm , на сервере проверила с php-fpm, дома с 5.3.4 cli (Gentoo)
и там и там -mfpmath=sse , так что FPU x87 для проявления ошибки не задействован,а вот в убунте собирают с -mfpmath=387, да и в остальных бинарных дистрах для x86 тоже, включая и archlinux , так что там по идее должно бы и проявляться зависание интерпретатора , причем способ вызова должен быть не важен, т.к. это в ZendEngine
Да, как модуль тоже не работает. И PHP 5.2.6-1+lenny9 тоже один хрен ничего не виснет, хотя округлил иначе.brutal@debian-printer1:~$ php -r "\$a = 2.2250738585072011e-308;echo \$a + 0;"
2.22507385851E-308brutal@debian-printer1:~$ php -v
PHP 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 4 2010 03:25:57)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
brutal@debian-printer1:~$Может и сухосин.
ЗЫ Попробовал почитать обсуждение, там какой-то матан. =) Ну его, не работает и хорошо.
Да, действительно, на Lenny не зависает. А на squeeze и sid при запуске через cli процессор начинает занимать 100%.
> Zend/zend_strtod.c
> патч на этот файл, zend engine собирается одинаково в любом случае, что
> cli, что cgi, что mod_php , что php-fpm , на сервере
> проверила с php-fpm, дома с 5.3.4 cli (Gentoo)
> и там и там -mfpmath=sse , так что FPU x87 для проявления
> ошибки не задействован,
> а вот в убунте собирают с -mfpmath=387, да и в остальных бинарных
> дистрах для x86 тоже, включая и archlinux , так что там
> по идее должно бы и проявляться зависание интерпретатора , причем способ
> вызова должен быть не важен, т.к. это в ZendEngineZend/zend_float.h
/* Copy of the contents of xpfpa.h (which is under public domain)
See http://wiki.php.net/rfc/rounding for details.Cross Platform Floating Point Arithmetics
This header file defines several platform-dependent macros that ensure
equal and deterministic floating point behaviour across several platforms,
compilers and architectures.The current macros are currently only used on x86 and x86_64 architectures,
on every other architecture, these macros expand to NOPs. This assumes that
other architectures do not have an internal precision and the operhand types
define the computational precision of floating point operations. This
assumption may be false, in that case, the author is interested in further
details on the other platform.For further details, please visit:
http://www.christian-seiler.de/projekte/fpmath/Version: 20090317 */
/*
Implementation notes:x86_64:
- Since all x86_64 compilers use SSE by default, it is probably unecessary
to use these macros there. We define them anyway since we are too lazy
to differentiate the architecture. Also, the compiler option -mfpmath=i387
justifies this decision.General:
- It would be nice if one could detect whether SSE if used for math via some
funky compiler defines and if so, make the macros go to NOPs. Any ideas
on how to do that?MS Visual C:
- Since MSVC users tipically don't use autoconf or CMake, we will detect
MSVC via compile time define.
*/
а патч радует ))- double aadj, aadj1, adj;
+ volatile double aadj, aadj1, adj;XDDDDDDDDDDD
На x86 FreeBSD-6 + PHP 5.3.4 + Suhosin баг воспроизводится, так что сухосин тут не панацея. :-/
PHP 5.2.16. Проверил в CLI и модулем апача - ничего не виснет. x86_64, сборка с -march=amdfam10
написанно же(в x86_64 вместо x87 используются инструкции SSE2)
а вот у мня тож не зависает - x86
# php -r "\$a = '2.2250738585072011e-308';echo \$a + 0;"
# 2.2250738585072E-308# php -v
PHP 5.2.6 (cli) (built: Oct 11 2008 01:21:44)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies
with Zend Optimizer v3.3.7, Copyright (c) 1998-2007, by Zend Technologies# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 1.70GHz
stepping : 6
cpu MHz : 600.000
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr mce cx8 mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe up est tm2
bogomips : 1196.84
у меня зависло php 5.3.2
Да, пишут, что -mfpmath=sse спасает
http://www.reddit.com/r/programming/comments/evtrq/php_hangs...
Implementation notes:x86_64:
- Since all x86_64 compilers use SSE by default, it is probably unecessary
to use these macros there.
Факт, у меня одно ядро на 100% занимается
Вот, выглянуло солнышко, и в debian sid прилетел пакетик php 5.3.3-7php -r "\$a = 2.2250738585072011e-308;echo \$a + 0;"
2.2250738585072E-308интересно, когда это в squeeze попадёт?
еще дохнут сайты с "левыми реализациями" json, которая (самая распространенная) содержит floatval().Кстати, дохнет не только пхп, а судя по всему, вся нить в ядре. Ядро, правда, после снятия процесса, отмирает :)
> еще дохнут сайты с "левыми реализациями" json, которая (самая распространенная) содержит
> floatval().
> Кстати, дохнет не только пхп, а судя по всему, вся нить в
> ядре. Ядро, правда, после снятия процесса, отмирает :)BSD? xD
На FreeBSD-6 завис только PHP-процесс (жрал проц на 100%), но вся остальная система работала нормально.
бубунта 9.04, xampp 1.7.1 ( Apache 2.2.11, php 5.2.9 )
<?php
$a = '2.2250738585072011e-308';
echo $a + 0;
?>
сразу выдало
2.22507385851E-308ничего не зависло
потому что обработало как строку , а не как float число
ну да, но только при
<?php
$a = '2.2250738585072011e-308';
echo $a + 1;
?>
выдавало "1"
а при
<?php
$a = '2.2250738585072011e-308';
echo $a - 1;
?>
выдавало "-1"то можно предположить что вычисление прошло успешно и зависания не было
This vulnerability is present on all versions of PHP including PHP 4.x and 5.x, on all Intel-based 32-bit PHP builds.Platform Vulnerable
Windows YES
Linux (using 32-bit PHP build) YES
Linux (using 64-bit PHP build) NO
Mac OS NO
IBM i NOhttp://www.zend.com/en/community/php/php-remote-exploit
Можно новость чутка обновить :))
> Mac OS NOМакоси не работают на 32-битных процах.
> IBM i NOОчень интересует наличие уязвимости на Plan9 под Alpha 21384 :)
главное тут
>all versions of PHP including PHP 4.x and 5.x)
Чой-то мене число "e-302" напоминает, так называемую "эпсилон" - машинный нуль, у любого процессора.
#include <stdio.h>int main(void) {
int k;
long double e, a;e = 1.0F;
k = 0;do {
e /= 2.0F;
a = e + 1.0F;
k++;} while ( a > 1.0F );
printf("\nЧисло делений на 2: %6d\n", k);
printf("Машинный нуль: %e\n", e);return 0;
}Число делений на 2: 64
Машинный нуль: 4.940656e-324Почти похоже :)
Надо ссылки читать просто:
>What’s Special About 2.2250738585072011e-308?
>2.2250738585072011e-308 represents the largest subnormal double-precision floating-point number; written as a hexadecimal floating-point constant, it’s 0x0.fffffffffffffp-1022. 2.2250738585072011e-308 is one of five 17-digit decimal values that convert (correctly) to 0x0.fffffffffffffp-1022:2.2250738585072007e-308
2.2250738585072008e-308
2.2250738585072009e-308
2.2250738585072010e-308
2.2250738585072011e-308http://www.exploringbinary.com/php-hangs-on-numeric-value-2-.../
> Only 2.2250738585072011e-308 causes the problem.Может 2011 связано как-то с текущим годом? :)
У кого есть PHP на 32-битах, переведите часы на месяц назад и
<?php
$a = '2.2250738585072010e-308';
echo $a + 0;
?>%-)
А чо часы то переводить ? Этой баге концептуально минимум лет 30, на моей памяти впервые она на спектруме еще в калькуляторе в 1982 году вылезла, и заключается она в неоднозначности машинного представления нуля с плавающей точкой. Тогда тоже округление от 65535 равнялось -1. То есть плюха вокруг разницы и одинаковости машинного преставления чисел +0, 0 и -0.Теоретически плюха эта будет работать не только в похапе, а вообще в любой программе которая скомпилена с поддержкой FP x87, ибо плюха эта сидит в самом x87 сопроцессоре. Просто в похапе ей технически как два пальца воспользоваться.
PHP 5.3.5 and 5.2.17 Released![06-Jan-2011]
The PHP development team would like to announce the immediate availability of PHP 5.3.5 and 5.2.17.This release resolves a critical issue, reported as PHP bug #53632, where conversions from string to double might cause the PHP interpreter to hang on systems using x87 FPU registers.
The problem is known to only affect x86 32-bit PHP processes, regardless of whether the system hosting PHP is 32-bit or 64-bit. You can test whether your system is affected by running this script from the command line.
All users of PHP are strongly advised to update to these versions immediately.