Сервер используется для предоставления хостинга, cPanel, apache 1.3.37.
Проблема:
Пользователь организует сервис, где посетители могут загружать файлы на сервер.
При загрузке проверяется расширение файла. В данном случае .mmf
Посетитель загружает 'file.php.mmf' и зная расположение, запускает его.
Сервер честно выполняет php код. Последствия понятны, я думаю.

Вопрос:
Как запретить обработку php в этом случае? Нужно сделать глобально для всего сервера.
Подскажите, пожалуйста.

http://dedic.ru/node/196

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

А почему mmf файл запускается в принципе? Ведь расширение не php?

Apache, вернее mod_mime, таким образом обрабатывает файлы, у которых несколько расширений.
Files with Multiple Extensions: http://httpd.apache.org/docs/1.3/mod/mod_mime.html
Получается, что файл test.php.* обрабатывается как php.

Поняли. Спасибо.

Тогда еще меньше проблем. php работает с правами пользователя и в чужой homedir не влезет.

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

Любопытная фича, мы бы пинали хостера в случае взлома через это При чём аргументированно Единственно чего не поняли, почему test.php.mmf виден результат работы скрипта, а по всяким test.php.zip , test.php.html, test.php.jpg не виден. Доку почитали, в меру нашего понимания там нет этому объяснения.

Так вот и пинают
Вот довольно мутная штука:

Мой httpd.conf:

Получается, что Handler как раз и выполняется.


Ха! Ему вообще по барабану последнее расширение.
http://nv.host3.road2web.com/phpinfo.php.kuku

Дырявость - в скриптах. Если бы был дырявый сервер - пострадали бы все сайты а не один.

Читали, и если правильно её поняли, то
test.php.zip , test.php.html, test.php.jpg - тоже должны показывать результат выполнения пхп скрипта, а у нас исходник отдается почему-то.

Не, у нас вопрос в другом. Из док понятно почему он может обрабатывать что попало, что нам непонятно, так это почему часть расширений он не обрабатывает
Это проще всего сказать, кроме как отмазкой такую фразу назвать никак не можем. Если Вы завтра сервер настроите так, что бы *.jpg файлы через php интерпретатор прогонялись, это тоже будет "дырявость в скриптах" по Вашему мнению, но это же бред. А логика идеально подходит - пострадают не все сайты, значит виноват не сервер. Если файл с именем "вася.php" и расширением "jpg" вдруг начинает обрабатываться пхп интерпретатором, этот вопрос должен решаться админом сервера, потому что обычный нормальный пользователь никак не ожидает что его легальные со всех точек зрения (кроме сервера) картинки будут запускать какие-то скрипты.
Кстати, вспомнили ещё один аргумент в пользу того, что сказанная Вами фраза не более чем отмазка. Давайте вспомним phpremoteview и хостинги где он работал. Или Вы будете утверждать, что и этот момент это тоже "дырявый скрипт", а не "криво настроенный сервер"? А ведь тоже "страдают не все сайты" и в первую очередь сайты с 777 директориями.

Все просто - если в результате взлома страдает один сайт - виноват владелец сайта.
Если страдают все сайты - виноваты настройки сервера.

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

Если взлом _сервера_ совершен в результате халатности, непредусмотрительности или умышленных действия администраторов сервера, то виноваты администраторы сервера.

Если взлом _сайта_ совершен в результате халатности, непредусмотрительности или умышленных действия владельца сайта, то виноват владелец сайта.

Наше мнение, что запуск интерпретатором php файла с именем "вася.php" и расширением "mmf" может быть возможен исключительно в следствии непредусмотрительности (заметьте, мы выбрали именно этот эпитет, а не другой из предложенного списка) администраторов сервера.

Не стоит путать первопричину и повод. Ещё раз сошлемся на пример с дирами 777 и phpremoteview и php как модуль апача... (который Вы выбрали оставить без комментариев). Когда так или иначе ломали через этот способ, достаточное количество хостеров сваливало вину на владельцев сайта - мол сами дураки - поставили 777. Ну да, конечно, сайты где не было 777 оставились без лишних загруженных файлов, но обвинять в установке прав 777 и как следствие взломе пользователя это уж, простите, через чур.

Здесь то же самое. Есть общепринятый термин расширение файла. Он большинством нормальных людей воспринимается как то, что идёт после последней точки. И если админ ставит софт на сервере который обладает дополнительными идеями по определению расширения файла - это непредусмотрительность админа.

И если завтра администратор проставит на сервер какой-нибудь ещё хитрый софт у которого будут свои идеи по поводу запуска, например, пёрл интерпретатора в зависимости от дня года и захода на сайт пользователя с IP с суммой цифр=4, то это никак не задача пользователя не допускать захода посетителей в такие моменты

Только не надо сейчас аргументировать в стиле "ну это же апач, все знают про обработку миме". Все и про 777 "знали", и это тоже "встроенный баг/фича" тем не менее у грамотных администраторов та фича с phpremoteview не работала и на пользователей они проблемы не сваливали.

Кстати, Вы можете объяснить почему test.php.jpg и test.php.html не отдает результат работы пхп скрипта, а отдает сам скрипт? Интересно же.

Порылся в справочнике, который Google называется...
Этот баг, который называют фичей:
http://www.net-security.org/vuln.php?id=3896

, известен давно: http://seclists.org/bugtraq/2004/Dec/0211.html
Есть и патч: http://secur1ty.net/mod_mime-handler-lastonly.patch
Почему разработчики это игнорируют, не понятно.
Пойду скрещивать easyapache и этот патч...

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

А у разработчиков php другое мнение и они не считают это ошибкой...

1) Это могло бы быть аргументом, если бы администраторы серверов настраивали их для разработчиков php.
2) Ссылочку на источник информации о мнении разработчиков php дадите?
3) Всегда считали, что надо руководствоваться не чьим-то там мнением, а общепринятыми определениями и понятиями.
4) Какое отношение разработчики php имеют к разработчикам програмного обеспечения обрабатывающего эти mime типы?

1) Если в реализации технологии разработчиками допущена ошибка, то дело ее исправления - задача разработчиков.
2) Смотрите выше - решение давно известно (в виде патча), однако разработчики не включают этот патч. Следовательно не считают данную особенность ошибкой.
3) С мнением ЦК КПСС тоже считались как с общепринятым понятием.
4) Прямое, см. выше.

1,4) При чём тут разработчики php? Если бы Вы сказали о разработчиках mod_mime или как там его, Ваш пример ещё как-то можно было бы понять.
2а) Смотрите выше пример про права 777, который Вы с упорством достойным лучшего применения игнорируете.
2б) Кстати, ссылки на то место где они утверждают что это не ошибка мы от Вас так и не увидели... А ссылка на существование патча это совсем другое.
3) Вы считаете что в современном мире применимы совковые методы работы?

Патчик работает отлично!
Наши серверы уже без этой фичи - дырки.

http://nv.host3.road2web.com/phpinfo.php
http://nv.host3.road2web.com/phpinfo.php.gif
http://nv.host3.road2web.com/phpinfo.php.html
http://nv.host3.road2web.com/phpinfo.php.kuku
http://nv.host3.road2web.com/phpinfo.php.mmf
http://nv.host3.road2web.com/phpinfo.php.txt
http://nv.host3.road2web.com/phpinfo.php5
http://nv.host3.road2web.com/phpinfo.php5.mmf

"Приятно видеть великоразумного человека" (с) (не помним откуда)

А Вы просмотрите html-код страницы.
Думаю оптимизма поубавится.

Не убавилось.
Там все правильно. Показывает содержимое файла, так как обрабатывать html как php приказа не было.

Пример – скачиваю файл http://nv.host3.road2web.com/phpinfo.php.mmf, открываю в notepad'e и вижу


И это нормально?

Да, это нормально.
Положите файл test.txt себе на хостинг, с вышеуказанным содержанием, и откройте. Увидите содержание точно такое же. Этого эффекта и требовалось добиться - что бы выводилось содержимое не php файла (по расширению), а не результат его работы.

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


Эх, прямо в четыре руки с edogs ответ писали.

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

1,4) Разработчики php при том, что реализация их технологии содержит множество потенциальных ошибок.
2a) Права 777 - это переход дороги на красный свет.
2б) Ссылка была дана выше не мной - перечитайте.
3) Нет. А по этому надо считаться не с мнением ЦК КПСС а с мнением более узкого числа людей.



Очень много. Но как человек, который специализируется на настройке серверов, я могу дать надежную рекомендацию по защите:
Сервер необходимо отключить от всех проводов и закрыть в большой сейф, который не пропускает вредных излучений.
Только в таком случае можно говоорить о надежной защите

А действительно. При чем здесь php?
Речь шла про фичи mod_mime, который входит в поставку apache.

Вопрос у меня лежал в другой плоскости.

Ну да ладно с ним.

1,4) Летят 2 крокодила, один зеленый, другой свистит красным свистом. Ещё раз спрашиваем - какое отношение имеют разработчики php к модулю apache ? Впрочем вопрос уже риторический, см. п.3.
2a) Мы говорили не просто про права, Вы опять ушли от ответа на вопрос.
2б) Ссылок в теме было дано очень много. Мы просили не просто ссылку, а ссылку на подтверждение Ваших слов в смысле "разработчики php знают об этом и считают это фичей". Её в топике нету, ни в Ваших постах, ни в чужих.
3) От четких ответов на вопросы Вы уходите. Приписали утверждение разработчикам php, но не дали ссылку в подтверждение своих слов. Не объяснили какое отношение разработчики php имеют к apache. При настройке apache предпочитаете ориентироваться на мнение узкого круга людей - разработчиков php, и а общепринятые понятия и термины по боку, так же как возможно мнение разработчиков apache:). А учитывая то, что при всём при этом, Вы начали с отмазки "администраторы ни в чем не виноваты", у нас вопросов к Вам больше нет.

Ни в коем случае не говоря о ком-то конкретно, хотели бы по мотивам топика и предыдущих общениях с разными администраторами (не одним конкретным! любые совпадения с присутствующими в топике случайны!) высказать своё мнение.
Если бы мы нанимали админов настроить сервер, мы бы предпочли таких админов, которые руководствуются общепринятыми понятиями и терминами, а не мнением узкого круга людей, не имеющих отношения к настраиваемому продукту, да еще если нет возможности подтвердить то, что этот узкий круг людей имеет такое мнение. Крайне не хотели бы, что бы нанимаемые нами администраторы уходили от конкретных вопросов, которые могли бы показать их отношение к способу настройки сервера. Крайне не хотели бы, что бы администраторы не поставив какой-то патч, потом сваливали ответственность на юзеров. Считаем халатностью и непредусмотрительностью со стороны администраторов, если что-то работает не ожидаемым для заказчика образом. Крайне не хотели бы что бы администраторы заявляли нечто вроде "мы Вам всё настроим и все будет хорошо, а с вопросами не лезьте, это не Ваше дело и мы не нанимались Вам что-то объяснять", а потом проявлялись "фичи" с обработкой пхп левых файлов и записями в папки 777 и открытым анонимным фтп в рут директорию.
P.S.: Подозреваем что только что отпугнули многих администраторов от работы с нами
Извиняемся за оффтоп, возможно часть темы есть смысл отделить или прибить.

Обычно админы руководствуются требованиями заказчика, а не чьим-то другим

Своей трактовкой требований, а не требованиями. Это и есть ключевой момент.
А то заказчик поручит фирме Х настроить сервер безопасно, а потом там пхп будет на каждый чих срабатывать, а админы отмазыаться "разработчики батареек думают что это правильно":)
Можно конечно сказать, что заказчик должен четче высказывать свои пожеланию, но в общем-то понятно что так не получится. Правильно заданный вопрос содержит половину ответа, так что если заказчик способен сформулировать нечто вроде " хочу что бы мод_миме обрабатывал только .пхп файлы", то скорее всего ему сервер будет быстрее настроить самому, чем обращаться к администраторам

Можно заказать отдельно исследование того, какие патчи есть для повышения security например

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

Лично я конечно не знаю, да и доки не читал те, но может быть просто потому, что эти расширения (*.html *.zip и т.п.) известны серверу?



А если переезжать (тьфу-тьфу) соберетесь или просто на другой сервер в пределах того же хостинга?
Не проще в скриптах с аплоадом запретить загрузку файлов с расширением *.php.chtoto ?

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

А судя по описанному в этом топике


выходит примерно наоборот



Ну в таком случае желаю Вам оставаться довольными текущим


А я бы сравнил с прививкой - один раз переболели немного и забыли Но мне понятна Ваша точка зрения, продиктованная принципами и я ее уважаю

Вот это и настораживает Или мы резко не так поняли или что-то резко не так работает.
Лучшее враг хорошего