Я читал, что пхп в режиме cli считывает php.ini в каталоге, где лежат сами выполняемые скрипты. А про cgi такого не знал. Если я не ошибаюсь, для этого его нужно допиливать было.

Я не стал с этим копаться, а как раз в свое время поправил suexec и через PHPRC.

Я его задавал в админс :( Речь шла про замену стандартного интерпретатора РНР на Resin (который в свою очередь переводит все это в жабу и потом выполняет)

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

все бы ничего, но надо сначала код инжектнуть? ;)

хотя для ССЗБ шарных хостингов может быть и проблема.

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

а подумать - что значит
--with-config-file-scan-dir=/usr/local/etc/php
в configure
- религия запрещает?

Ты всё ещё не понимаешь проблему. :) Без всякой инжекции можно за пол-копейки стать клиентом шаред-хостинга, и защищать нужно прежде всего от других клиентов, а не от каких-то внешних атак.

В FreeBSD в портах пофиксили:
http://www.freshports.org/lang/php4/

16 Oct 2006 09:30:58
4.4.4_1

- fix open_basedir vulnerability in php4 and php5 [1]
- add an alert on safe_mode intrinsic insecurity and
suggest to install the suhosin extension
- enable the suhosin patch by deafult also in php4

> экзешник php лежит в cgi-bin и запускается как CGI
а Вы вообще в курсе разницу между CGI php и mod_php?
это - кривое решение,
по сути - костыль

>Ты всё ещё не понимаешь проблему. :) Без всякой инжекции можно за пол-копейки стать клиентом шаред-хостинга, и защищать нужно прежде всего от других клиентов, а не от каких-то внешних атак.

да нет, это ты невнимательно прочитал мой пост, на который ответил

прочти пожалуйста еще раз - ок? :)

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

Эта опция как раз не при чём, совсем. В этой директории ищутся дополнительные конфиги для PHP (то есть там читаются все файлы с расширением .ini), а вот основной php.ini ищется сначала в текущей директории, а потом, если его нет, берётся общесистемный /usr/local/etc/php.ini.

> религия запрещает?

Меня каждый раз поражает, с каким апломбом здесь некоторые демонстрируют своё невежество. Психически здоровый человек просто сказал бы: "а эта опция случайно не то, что тебе нужно?" Но нет, нам надо показать своё мифическое превосходство. :)

если честно -я таки не понял -чем Вам register_globals не угодил?

я его активно пользую - собственно эта фишка была одной из тех из-за чего на PHP приходят.
а если какой-то чудак не в состоянии в своём prepend_script проинить все свои используемые переменные и массивы - то ему и Java не поможет.:)

> а если какой-то чудак не в состоянии в своём prepend_script проинить

Ты никогда не ошибаешься, да? :)

И тебе трудно написать $_GET[] или как там оно...

>я его активно пользую - собственно эта фишка была одной из тех из-за чего на PHP приходят. а если какой-то чудак не в состоянии в своём prepend_script проинить все свои используемые переменные и массивы - то ему и Java не поможет.:)

ну дык вроде все поняли? ;)))

для "крутых" программистов вроде вас - register_globals не проблема

но ведь "чудаки" тоже имеют право на существвание? ;)))

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

Три гениальных высказывания, которые спасут Россию :)

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

На django

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

Сергей, я ничего не спрашивал :) И как-то не хочется даже спорить насчёт сделанных далеко идущих выводах о моём слабом знакомстве и прочем неведении. Но я нигде не заикнулся насчёт того, на что у апача хватит прав. Пример-то был про /etc :)

Ладно, сорри за далеко идущие выводы, но на самом деле я тебе просто позавидовал. :)

> Аналогичная история с register_globals...

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

Какие тут нафиг ужасы. Пипл требует register_globals. Не то что хавает, а прямо-таки требует. Соответственно, пипл register_globals имеет (хотя и не на всех серверах, а на специально выделенных отстойниках). В принципе, это не проблема, так как во-первых проблема тут прежде всего для самого админа сайта, который это хочет, а во-вторых, register_globals легко включить/выключить в .htaccess. А phpinfo() на новом хостинге в любом случае читать надо, и смотреть что там для тебя правильно а что нет.

Бывает, что нет возможности почитать phpinfo() до того, как проплатишь. Те же, кто купил и поставил phpBB наверняка совсем не смотрят, а сколько их таких...

Увы им. :) Но даже если нет возможности её почитать (хотя непонятно зачем до этого вообще платить), то уж поменять что надо в .htaccess возможности есть наверняка.

>Бывает, что нет возможности почитать phpinfo() до того, как проплатишь.

moneyback? trial? ;)

>Те же, кто купил и поставил phpBB наверняка совсем не смотрят, а сколько их таких...

это уже головная боль хостера - изолировать их один от другого и на РНР здесь надеятся нечего ;)))

Ужасы нашего городка.

Нужен XMLDOM. Ну дададад, дыра, но если следить, то не совсем дыра. Мы к хостеру: давай, партнер, подсуетись. Так он полдня пересобирал PHP с новыми опциями.

Я туда на шелл захожу... Мама дорогая. По виду RedHat какой-то, а все добро запускается с какой-то сущей слаки в /usr/local, куда они все ручками собирают.

Разве за это руки отрывать нельзя?

> я его активно пользую - собственно эта фишка была одной из тех из-за чего на PHP приходят.

Меня она наоборот, в своё время испугала и я предпочёл Perl :-)

> а если какой-то чудак не в состоянии в своём prepend_script проинить все свои используемые переменные и массивы - то ему и Java не поможет.:)

Ну как раз Java поможет, да и Perl тоже (программер обязательно использует "use strict; use warnings;" || ССЗБ).

Спорный вопрос :-) Баланс производительность/безопасность. Для масс хостинга - вполне может быть терпимым CGI+suexec. Дабы не пихать кучу дырявых phpшных модулей в серверный mod_php.

Еще такая штука (сыроватая..) как Peruser MPM для apache2 есть.

> Я туда на шелл захожу... Мама дорогая. По виду RedHat какой-то, а все добро запускается с какой-то сущей слаки в /usr/local, куда они все ручками собирают.

Уверены что ручками? Что не из rpm-ку свою ставят?

Если это действительно хостер - почему бы ему не пользовать свои сборки apache, php..

> Уверены что ручками? Что не из rpm-ку свою ставят?

Более чем. Они каждый раз, когда клиенту на шаредхосте (!) что-то особое нужно, пересобирают руками. Кстати, у них на это полдня почему-то идет.

Видимо, разделяемых библиотек не осилили.

> Более чем. Они каждый раз, когда клиенту на шаредхосте (!) что-то особое нужно, пересобирают руками. Кстати, у них на это полдня почему-то идет.

Ну, давайте думать о людях хорошо :-). Предположим, что это время уходит в том числе - на тестирование получившегося конгломерата расширений, модулей - с их хостинговой средой...

Хотя я бы работать с хостером, меняющим конфигурацию по каждому чиху - не стал бы. Нужны нестандартные расширения - FastCGI + PHP-интерпретатор как CGI скрипт.

hans

> трудно написать $_GET
и чем это поможет? ах да, вместо того чтобы просто использовать
$sernum; я должен буду пистаь $_GET['blah-blah-blah...sernum']
ребята - это мы уже проходили - кол-во ляпов в C++ программах почему-то сравнимо с C.

hans

> "чудаки" тоже имеют право на существвание?
между прочим, мастреа жанра советут: KISS. последняя S - это stupid.
для начала - прочитайте полезную книжку Кернигана про то, как грамотно и хорошо писать на C и других языках.
разруха не в register_globals, разруха - в головах.

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

Я поменяю, и толку? Сосед не поменяет, ломанут его, а потом через эту дырку и меня ломать начнут. Ну да ладно, чего это я вдруг разнылся.

Анатолий, всё сказанное абсолютно верно. Но "начальникам" как всегда виднее.

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

Да ты что! А suEXEC пользователя под которым скрипт запускается не меняет уже?

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

А где ты видел в обсуждении до вот этого своего поста упоминание о mod_php? Вообще то обсуждали php целиком, и как его применяют на сервере.

> Типа без тебя этого кто-то не знает?

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

mod_php 4.4.2 - эксплоит не работает suexec, cgi 5.0.4 - та же фигня.

>> Еще такая штука (сыроватая..) как Peruser MPM для apache2 есть.

Где? Я всё ждал когда допилят, но в 2.4(?)и её наоборот - отпилили.

>> $sernum; я должен буду пистаь $_GET['blah-blah-blah...sernum']

а покурить маны? что за бла-бла-бла? $_GET['sernum']

$_GET

ага, только слегка усложним дело - sernum - массив из формочки select box. в гробу я двойные массивы видал! KISS!

http://www.telana.com/peruser.php

> и чем это поможет? ах да, вместо того чтобы просто использовать $sernum; я должен буду пистаь $_GET['blah-blah-blah...sernum']

Можно написать подобные вещи в скрипте один раз :-) И потом работать с $sernum и т.д.

$_GET

> Можно написать подобные вещи в скрипте один раз
ну дык о чём речь!
Расмус уже это сделал. не вижу смысл плодить велосипед к тому же более медленный.;)

Вот упёртый чел =), сходи почитай почему register_globals нужно выключать.

http://alxumuk.com.ru/index.php?option=com_content&task=view&id=1743&... http://www.kyrnet.kg/instruct/faq_php/

и чо? ничего нового. автор со всех сторон обсасывает как плохо делать ошибки и как много способов хакнуть через register_globals - можно подумать лемминги не нашли способ подставить через _GET!;)
да вот хотя бы: http://www.lexa.ru/security-alerts/msg00246.html

> и чо? ничего нового. автор со всех сторон обсасывает как плохо делать ошибки и как много способов хакнуть через register_globals

Включенные register_globals - это способ незначительно повысить удобство при создании программы ценой её меньшей безопасности. Много ли выигрывает программист из-за того, что куки и параметры запроса превращаются в переменные? Экономия может быть порядка десятка строк. А цена? Достаточно высокая опасность взлома. По всей видимости большинство взломанных машин под Linux были взломаны именно из-за включенных register_globals. Можно конечно посчитать, что их владельцы сами себе злобные Буратино, их предупреждали, что не следует включать register_globals (насколько я знаю, по умолчанию эта функция отключена), но вы нам статистику портите :-) Посторонний человек вряд ли станет вникать в подробности, что причина взлома - сознательная неправильная конфигурация сервера, он просто скажет: "Linux тоже взламывают".

Надо просто использовать fastcgi+suexec, а mod_php вместе с safe_mode - фф топпку. Кстати, fastcgi - это не только mod_fastcgi. Это намек для любителей заявлять что mod_php позволяет больше юзеров на один сервер запихать :)