Обход ограничений open_basedir в PHP 5.2

Блин, проверяйте входный данные и будет вам счастье. Не в инструменте дело, а в мозгах. Язык не спасет Вас, если руки растут из жо**

Я то чо, я JSP учу ;)

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

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

Теже яйца = вид сбоку. Я лично особого дискомфорта в переходе с питоне не почуствовал(кроме кавычек, но это удел веб). Или язык должен быть сложным, непонятным?

Руки надо выпрямлять, а не на язык ориентироваться. Если Вы(это ко всем) не проверяете данные - Вы, сэр, и есть было. И не важно на каком языке Вы пишете.

Чисто теоретически на php можно писать безопасный код, но тех кто способен это делать очень мало.

На python фреймворках писать безопасный код проще.

баги в safe mode не расстраивают -- все одно от него больше проблем чем пользы. а вот php меня расстроил недавно -- изумительно хреново у него как оказалось gc работает, не удаляет объекты с циклическими зависимостями. кроме того, когда и чистит -- все одно течет сильно. а уж какие тормоза начинаются после того как много-много объектов зараз удалить..

иэх. это из оперы -- надо было cpp юзать..

И вобще, open_basedir в топку. Каждому пользователю по fastcgi php серверу запускающемуся от имени пользователя, ssh доступ и возможность редактировать конфиги, и пусть делают что хотят.

>хреново у него как оказалось gc работает, не удаляет объекты с циклическими зависимостями

Любой gc не удалит данные, пока на них есть хоть одна ссылка (пока эти данные не станут garbage) - чему тут удивлятся. Ну и тормозам при удалении "много-много" удивлятся не стоит - все знают о Java'всих слабостях, но до сих пор удивляются тем же методам в других технологиях? Работать надо со знанием дела, вот и все...

Ах, да. PHP - сакс. Ruby спасет мир. А Java под GPL поможет.

Мне кажется, что данная уязвимость притянута за уши.

Во-первых, open_basedir - это дополнительная мера безопасности, никак
не главная. В каких ещё языках встроена такая фича? У большинства её
вовсе нет.Они уязвимы по определению? ;)

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

В-третьих, что можно добиться, зная эту "уязвимость"? Где эксплойт?

Зацените количество:

http://www.securityfocus.com/cgi-bin/index.cgi?c=12&vendor=PHP

>нужно как минимум иметь права на запись в каталоге за пределами basedir

ну а я только какой-нить *.c(on)?fg? прочитать хочу, а там уж посмотрим...

> Любой gc не удалит данные, пока на них есть хоть одна ссылка

а повнимательнее почитать? :-)

> тормозам при удалении "много-много" удивлятся не стоит

вот в том-то и дело что тормоза не во время удаления, а сильно после. такое впечатление что php не нравится собственная освобожденная память. фрагментация? не знаю, плюнул.

> Ruby спасет мир

не без того :-) после того как его станут ставить на всех хостингах подряд :-)

> Во-первых, open_basedir - это дополнительная мера безопасности, никак не главная. В каких ещё языках встроена такая фича? У большинства её вовсе нет.Они уязвимы по определению? ;)

Ну, например, что-то подобное open_basedir/safe_mode есть в parser. Хотя, имхо, парсер ничем не лучше php.

> 2, 3

Сплойт есть в "подробностях", чЕтатели ;-) На массовом вирт хостинге вполне актуально - можно залезть в хом другому пользователю, коли апач имеет туда доступ.

>не без того :-) после того как его станут ставить на всех хостингах подряд :-)

А 100$ в месяц на размещение своего сервера жалко? Или в крайнем случае на обычном компе поставить все нужное.

> Блин, проверяйте входный данные и будет вам счастье.

Чукча писатель, явно. Причём на PHP. :)

При чём тут проверка входных данных? Проблема в том, что админ сайта может обойти ограничения, наложенные на него админом сервера.

Perl спасал и спасёт мир. Ни у PHP, ни у Ruby ничего подобного CPAN нет.

> А 100$ в месяц на размещение своего сервера жалко?

есть слишком много задач когда жалко. и времени/денег на администрение тоже жалко. php берет в частности тем что он везде есть. а потом когда есть выбор между софтом аппробированным на миллионной установочной базе и софтом который видело всего несколько человек -- что выбрать даже для своего сервака?

> Perl спасал и спасёт мир.

перл скоро будут вспоминать в том же контексте что и os/2. до сих пор говорят некоторые пользуют кстати.

Perl выполняет свои задачи с успехом, а значит его никто не забудет. К тому же скоро будет стабильный perl 6.

>Любой gc не удалит данные, пока на них есть хоть одна ссылка (пока эти данные не станут garbage) - чему тут удивлятся.

Удивляться тому, что в JRockit проблема с циклическими ссылками решена. У PHP, как всегда руки ростут из ж###

>Perl выполняет свои задачи с успехом, а значит его никто не забудет. К тому же скоро будет стабильный perl 6.

Почему я это слышу больше года?

Вопросы о хостинге Руби:

http://wiki.rubyonrails.ru/rails/show/Хостинг

В первых строках гугла нашел. Какие проблемы?

> К тому же скоро будет стабильный perl 6.

это я уже пять лет слышу..

> Вопросы о хостинге Руби:

потому что язык подбирается под хостинг, а не хостинг под язык

> Вопросы о хостинге Руби:

мало в смысле

> Ну, например, что-то подобное open_basedir/safe_mode есть в parser.

Здесь обычно идёт сравнение с ruby, perl, python. У них нет аналога
open_basedir. Читаем любые доступные на чтение файлы без всякого
эксплойта ;) Так кто более безопасен?

> Сплойт есть в "подробностях", чЕтатели ;-)

Ткните меня носом, плиз, в место с эксплойтом. Я нашёл лишь цитаты из
кода самого php и теоретические разлагольствования на тему возможного
эксплойта. Готового эксплойта там нет. Дайте инструкцию, как мне
прочитать, к примеру, /etc/passwd с помощью этой "уязвимости".
Классический пример доступного всем на чтение файла, который хотелось
бы скрыть от скриптов.

open_basedir это часть safe_mode. Открываем ман по РНР (http://ua2.php.net/manual/en/features.safe-mode.php), вдумчиво смотрим на фразу: Warning Safe Mode was removed in PHP 6.0.0. Еще более вдумчиво, на фразу:

The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now.

Абсолютно согласен. Управлять доступом на уровне РНР не верно в принципе. Если кому-то хочется безопасности, ставьте suphp, пускайте РНР под разными юзерами, рулите правами доступа системы. И будет вам счастье и секурность.

P.S. Как писатель на РНР не понимаю смысла в safe_mode и, тем более, не понимаю тех кто запускает с этими опциями РНР. Усложняет жизнь разработчику при этом ничего не дает.

>Ни у PHP, ни у Ruby ничего подобного CPAN нет.

У PHP есть PEAR, у Ruby - Gems. gem также прост и удобен, как cpan.

> Как писатель

Во-во. А там чётко написано, что ISP приходится этим пользоваться. Причина - разница в нагрузке на сервер между PHP как CGI и модулем апача. Хотя ISP и не таким приходится пользоваться, взять сам PHP к примеру... Психически здоровый человек этим пользоваться не станет, однако клиенты ("писатели") требуют...

Там не написано что _приходится_. Safe mode не дает ничего. Да, средствами РНР нельзя достучаться выше определенной папки, но никто не мешает сделать `cat /home/another_user/secure_data` и получить все что нужно. Про запрет на выполнение шел-кода говорить не будем. Очень часто он действительно нужен.

Почему это не будем? Очень даже будем. Таки запрещаем и всё. Цель - построить максимально дешёвый хостинг, перебьётесь без шелла. Тем более что чаще всего он как раз нафиг не нужен.

Скорее "максимально фиговый хостинг". Возьмем самую дешевую/слабую машину, запустим там самый легкий язык программирования, настраивать ничего не будем (потому как время = деньги) и начнем продавать самый дешевый хостинг. Причем дешевый, не только в плане цены. P.S. "Чаще всего" - на страницах класса "домашняя страница меня и моего кота" -- да, не нужен. Однако на серьезных проектах он очень даже нужен. И серьезные проекты на такой хостинг ценой не заменить никак.

Опять же, у того же самого Перла таких ограничений нет, и никого это не беспокоит.

Оффтоп: Несколько пугает отношение к клиентам. Что значит "перебьётесь"? Скорее вы "перебьётесь" без клиентов.

Ну, ещё один. Ты вообще понимаешь что не все готовы платить не то что $100, а даже $10 в месяц за хостинг? Да/нет, после этого будем говорить дальшу.

Второй вопрос, ты понимаешь, что за разную сумму предоставляется разный набор услуг? Да/нет.

Достали знатоки единственно правильного пути.

1. Да
2. Да.

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

Опять же, из парадоксов safe_mode. Вы знаете о извечной его проблеме, когда человек не может изменять/удалять файлы, которые залиты были через веб?

> 1. Да 2. Да.

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

> Вы знаете

Знаем. И?

safe_mode сам по себе тут кстати вообще не при чём.

> Ах, да. PHP - сакс. Ruby спасет мир. А Java под GPL поможет.

PHP должен мучительной смертью умереть.

> потому что язык подбирается под хостинг, а не хостинг под язык

Какая невероятная дикость!

>Тем более что чаще всего он как раз нафиг не нужен.

А вы сами что-нибудь размещали на хостинге. Или, вы так сказать

"писатель". И как его без шелла администрировать (я имею в виду сайт).

А никогда не наблюдали вопли владельцев магазинов, что злой "хакер"

залез в админку и все там перепортил. И очень много (большинство?)

магазинов кстати на виртуальном хостинге.

P.S. Это вы сами придумали, что цель-построить максимально дешевый

хостинг?

P.P.S. Знаю одного Питерского хостера, который не предоставлял шелл

доступа. Хотя цены у него как и у других. Вы случайно не у него

работаете.

ПРОСТО ЗЛА НЕ ХВАТАЕТ!

>А вы сами что-нибудь размещали на хостинге. Или, вы так сказать

Лично я - размещал, и не раз.

>"писатель". И как его без шелла администрировать (я имею в виду сайт).

Грамотно написанный сайт вполне себе можно администрировать без шелла. С шеллом, нет спора, удобнне. Ну так и покупайте тарифы не за 3$ и все будет хорошо.

>А никогда не наблюдали вопли владельцев магазинов, что злой "хакер" залез в админку и все там перепортил. И очень много (большинство?) магазинов кстати на виртуальном хостинге.

Ну так это - по тупой жадности владельцев. Если магазин приносит деньги, а владельцам жалко потратиться на dedicated / colocation, то, увы. Это - не проблема массового вебхостинга.

>P.P.S. Знаю одного Питерского хостера, который не предоставлял шелл доступа. Хотя цены у него как и у других. Вы случайно не у него работаете. ПРОСТО ЗЛА НЕ ХВАТАЕТ!

Нормальные хостеры вполне себе предоставляют шелл. Даже на относительно дешевых тарифных планах. Те же Zenon или .masterhost.

>покупайте тарифы не за 3$ и все будет хорошо.

Пару лет назад, infobox (если не ошибаюсь) не предоставлял шелл на

виртуальном хостинге вообще. Это и к вопросу о нормальных хостерах.

>Если магазин приносит деньги, а владельцам жалко потратиться на

dedicated / colocation, то, увы.

Тут вы конечно правы (с магазинами), но ведь существуют не только

магазины.

Говорить, что шелл не нужен вообще- странно. Можно ведь и транспортом

не пользоваться, пешком ходить.

>Грамотно написанный сайт вполне себе можно администрировать без шелла.

Не знаю, не знаю. Я бы не стал этого делать. Во первых с шеллом

удобнее, а во вторых - безопаснее.

Никто не говорит, что шелл не нужен. Но предоставление шелла требует дополнительных мер безопасности, и в определённой ценовой нише оправдан отказ от шелла. Иначе этой ниши просто не будет.

> open_basedir это часть safe_mode.

Где такое написано? open_basedir - самостоятельная опция в конфиге, ни
с кем не связанная.

> The PHP safe mode is an attempt to solve the shared-server security problem.

Ну, вот, первая ложь рождает вторую. Я повторюсь, open_basedir не
связана с safe_mode и решает другую задачу. Это скорее проблема privacy,
а не security. Не дать читать файлы, которые формально разрешено
открывать на чтение, но по мысли администратора неплохо бы прикрыть.