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