Какие хостинги ломают

Зингельшухер, Спасибо за инфу. Но я с этим ни разу не сталкивался. Поэтому и описал про то как действует стандартный апач. Я больше по Домино специализируюсь, там есть аналогичный режим xSP. Но это не модуль а свойство ядра. Да и все ли хостеры этот режим ставят? и насколько он загружает сервер?

Все кроме ламеров которые у себя дома на модемах апачь на винду ставят и думают что стали крутыми хостерами :)

(опять-же я говорю ОЧЕНЬ упрощенно чтоб избежать непонимания)

Действительно ответ уж очень упрощёный.

Существует mod_suexec который позволяет запускать cgi'ки под теми

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

требуется лишь включить его при сборке апача указать --enable-suexec,

и в httpd.conf'е указать для вирт хоста user & group.

Но ведь существует и mod_php который этого то как раз не умеет.

И выполняется оно с правами пользователя указаного в настройке апача = user.

Обычно эта дыра закрывается включёным safemode, и запретом скриптам на php

подниматься выше документ_рута путём наложения соответствующих патчей и модулей. Или же использование соответствующих модулей уже для php.

Но это требует весьма грамотной и ювелирной настройки.

Любая ошибка со стороны администратора сервера или разработчиков

панели (ох уж эта cP!), приведёт как раз к массовым взломам у хостера.

Однако есть VDS, VPS (привет swsoft =)), в которых даже рут выше

домашнего каталога подняться не может. Или в FreeBSD Jail, окружение + отдельный апач каждому юзеру (да много хостов так не заведёшь на машинку, но зато если поломают соседа, то тебе это ничем не грозит).

Вот чуть менее упрощёная ситуация.

Если где-то ошибся, прошу поправить.:)

Из всех хостеров что я пробовал (платных и бесплатных) эта дыра была только у одного британского студента который сделал свой "хостинг" на домашнем компе (Win2k/Apache1.3/PHP4.3.x) что привело к логичному завершению, т.е после 10-го взлома он закрыл свой "хостинг" (слава богу далеко не все дамины хостингов ламеры)

Но открывается ряд других :)

Не всегда так апач работает ;)

Можно протсо заблокировать ряд php функций и шел даже если и зальют, работать не будет.

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

Тов. og уже перечислил основные постулаты - отсутствие mod_php, изменения id пользователя у скриптов на лету и пр.

Помимо прочего есть еще такая штука как suPHP, но промышленно, вроде, ее не используют в силу ее глючности. Которая создана для изменения пользоваля при запуске php-скриптов при рабоче через mod_php.

Если упрощать ситуацию, то сломав клиентский аккаунт с каким-нить phpNuke или phpBB дальше его окружения вылезти не получится. Если вдруг это получится, то взломщик окажется внутри виртуальной машины, из которой доступа к мастер-машине он уже не получит. Т.е. разломать полностью при всем желании не удастся.

Поэтому, когда тиражируют такие "аццкие" новости это напоминает телевизор-дебилизатор с вечно торопящимися журналистами, у которых нет уже ни времени ни желания проверять информацию.

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

Когда выясняется что это была ложь то достаточно выпустить опровержение и свалить ошибку на третих лиц...

(многие порталы изобилирует такими "сенсациями", почему я в последнее время и читаю securitylab.ru не как информационный портал а как юмористический)

IMHO никакой гарантии... надо решать вопрос глобально, а именно на уровне выполнения скрипта в теле процесса с uid/gid клиента, что само по себе снимает массу головной боли. Классическая реализация данного механизма не позволяет получить хорошей производительности, поэтому приходится идти на различные изменения ядра и самого apache, причем такие изменения дают гарантию аналогичную suexec и прочему.

У меня процессы apache меняют свой uid/gid на лету, в зависимости от того на какой vhost прилетел запрос... причем процессу это разрешается 1 раз на 1 accept... все дальнейшие попытки процесса изменить свой uid/gid блокируются и логируются. Следовательно когда реквест отработан, то процесс будет висеть с этим же uid/gid до следующего запроса... а потом ему опять позволят изменить uid/gid.

При такой security модели shared хостинга достигается МАКСИМАЛЬНАЯ производительность php на shared и гарантия аналогичная suexec. Изначально, при внесении этих изменений, предполагался один риск - получения данных из директории другого клиента... никаких процессов apache запущенных из под root нет, в отличии от всяких suPHP и прочих, которые без кернел патчей.

Более того, т.к. параноя в плане секурити никому еще не вредила, то что бы попытаться сделать аналогичный вызов функции ядра, нужно как-то скомпилироваться с нужной либой (которая не доступна) или же проанализировать полушифрованный бинарник ядра, который само собой не доступен... или проанализировать полушифрованный бинарник apache, который тоже недоступен...

Помимо кучи проверок есть еще какие-то magic key's, которые нужно знать, что бы вызов ядра не дал отлуп... на всякий случай.

Если кто-то научится получать доступ из php к области памяти с бинарем, то он получит что-то, что без ключика никак нельзя расшифровать... само собой если он утянет кернел, то тоже 😂

Вот так надо делать shared хостинг... а не на всяких там suPHP и прочих... даже без проверки "1 раз на 1 accept" это работает как часы ибо сделать вызов нет возможности, особенно из php.

Хотя делают на rfork и прочем, но это подразумевает httpd из под root и большой оверхид... в описанной мною схеме нет-у rfork и т.д.

PS. Дистрибутив в виде кернел модуля + патчи на apache2.x.

Как это рашает проблему с клиентами заливающими всё по ftp с правами 777 ?