В PHP / Apache / контекст Linux, почему точно действительно ли chmod 777 опасен?
Вдохновленный обсуждением в этом вопросе, возможно, глупом вопросе.
Нам все преподавали что, оставляя каталоги или файлы на основанном на Linux веб-хостинге с уровнем разрешения 777 плохая вещь, и всегда устанавливать такие же маленькие полномочия по мере необходимости.
Мне теперь любопытно как, туда, где точно находится опасность эксплуатации, конкретно в PHP / контекст Apache.
В конце концов, файл Сценария PHP может быть выполнен с внешней стороны (т.е. через вызов к веб-серверу, и впоследствии к интерпретатору), неважно, отмечено ли это как "исполняемый файл", не так ли? И то же относится к файлам, названным через командную строку php интерпретатор, правильно?
Таким образом, где точно уязвимость с 777? Действительно ли это - то, что другие пользователи на той же машине могут получить доступ к файлам, которые сделаны перезаписываемым миром?
3 ответа
Вот один сценарий:
- У вас есть незащищенный каталог, в который пользователи могут загружать файлы.
- Они загружают два файла: сценарий оболочки и файл php с вызовом
system ()для сценария оболочки. - они получают доступ к только что загруженному php-скрипту, посещая URL-адрес в своем браузере, что вызывает выполнение скрипта оболочки.
Если это каталог 777, это означает, что любой (в том числе пользовательский apache, от имени которого будет выполняться скрипт php) может его выполнить! Если бит выполнения не установлен в этом каталоге и, предположительно, в файлах внутри каталога, то шаг 3 выше ничего не сделает.
отредактируйте комментарии: важны не права доступа к файлу PHP, а вызов system () внутри файла PHP, который будет выполнен как системный вызов linux пользователем apache linux (или чем-то еще у вас установлен apache для запуска как), и это ТОЧНО, где бит выполнения имеет значение.
Это значительно повышает уязвимость вашего сайта для вредоносной деятельности, потому что для этого нужно взломать только одну учетную запись.
Любой человек, получивший доступ к вашей системе с любым логином, может делать с вашими страницами все, что захочет, включая изменение их на "Этот сайт действительно небезопасен, поэтому, пожалуйста, предоставьте мне информацию о вашей кредитной карте."
EDIT: (Для уточнения и устранения замечаний)
Многие серверы имеют более чем одну цель в жизни. Они запускают несколько служб. Если вы тщательно изолируете эти службы друг от друга, назначая каждой из них уникального пользователя и соответствующим образом управляя разрешениями на файлы, да, вы все равно окажетесь в горячей воде, если кто-то скомпрометирует учетные данные учетной записи, но ущерб, который он может нанести, будет ограничен этой одной службой. Если у вас просто одна общая учетная запись и вся файловая система настроена на 777, одна взломанная учетная запись ставит под угрозу все на машине.
Если ваш сервер предназначен только для запуска Apache/PHP и не служит никакой другой цели в жизни, и есть только одна учетная запись, под которой запускается Apache/PHP, взлом этой одной учетной записи равносилен взлому всей машины с точки зрения вашего приложения (хотя у вас все еще должны быть защищены системные файлы, которые не могут быть записаны учетной записью, используемой для запуска PHP... это возможно только для учетной записи администратора/root).
Если они могут записать файл, и он является исполняемым, они могут изменить его на что-то, что выполняется на вашей машине (исполняемый файл или скрипт), а затем использовать shell_exec PHP для запуска этого исполняемого файла. Если вы настроены на запрет shell_exec, они могут изменить и вашу конфигурацию
.Есть много веских причин придерживаться минимализма в отношении прав доступа, но в контексте LAMP-хостинга, несколько из них приходят на ум:
- На платформе виртуального хостинга другие пользователи, пользующиеся вашим хостом, могут читать и писать ваши скрипты.
- На выделенном хосте неавторизованные процессы могут читать/писать и случайно удалять ваши файлы. Допустим, есть пользовательский процесс протоколирования, запущенный в фоновом режиме от имени пользователя nobody, который имеет ошибку, в результате которой он пытается
rm -rf /. Как правило, это безвредно, поскольку вряд ли найдется файл, на который никто не должен иметь прав на запись, но теперь этот неавторизованный процесс заберет с собой ваши файлы. - Чтобы испортить ваш сайт, кто-то должен получить доступ от имени любого пользователя, даже
nobodyили какой-нибудь фиктивной учетной записи. Как правило, злоумышленнику придется провести еще одну атаку эскалации уровня пользователя, чтобы добраться до места, где он сможет нанести ущерб. Это реальная угроза. Некоторые некритичные службы могут работать под фиктивными учетными записями и содержать уязвимость.