В контексте PHP/Apache/Linux, почему именно chmod 777 опасен?

Вдохновленный обсуждением в этом вопросе, может быть, глупый вопрос.

Нам всем научили, что оставлять каталоги или файлы на веб-хостинге на базе Linux с уровнем разрешений 777 - это плохо, и устанавливать всегда как можно меньше разрешений.

Мне любопытно, где именно лежит опасность эксплуатации, особенно в контексте PHP/Apache.

В конце концов, файл PHP script может выполняться извне (то есть через вызов веб-сервера, а затем и интерпретатору) независимо от того, помечен ли он как "исполняемый файл", не так ли? То же самое относится к файлам, вызванным через интерпретатор командной строки php, правильно?

Итак, где именно уязвимость с 777? Является ли тот факт, что другие пользователи на одном компьютере могут получить доступ к файлам, доступным для записи в мире?

Ответ 1

Здесь один сценарий:

У вас есть незащищенный каталог, который пользователи могут загружать.
Они загружают два файла: оболочку script и php файл с вызовом system() в оболочку script.
они получают доступ к php script, которые они просто загружают, посещая URL-адрес в своем браузере, вызывая выполнение оболочки script.

Если этот каталог равен 777, это означает, что любой (включая пользовательский apache, который будет выполнять php script), может выполнить его! Если бит выполнения не установлен в этом каталоге и, предположительно, файлы внутри каталога, то шаг 3 выше ничего не сделает.

отредактируйте из комментариев: это не права на файлы PHP, которые имеют значение, это вызов system() внутри файла PHP, который будет выполняться как системный вызов linux от пользователя apache linux (или того, что у вас установлено для запуска Apache as), и это ТОЧНО, где имеет значение бит выполнения.

Ответ 2

Это значительно увеличивает уязвимость вашего сайта к вредоносному действию, потому что нужно только входить в одну учетную запись.

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

ИЗМЕНИТЬ: (Чтобы уточнить и отправить комментарии)

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

Если ваш сервер предназначен только для работы с Apache/PHP и не служит никакой другой цели в жизни, и существует только одна учетная запись, под которой выполняется Apache/PHP, причем эта учетная запись скомпрометирована так же хорошо, как и вся машина скомпрометированы с точки зрения вашего приложения (хотя вы все равно должны иметь системные файлы, защищенные и незаписываемые учетной записью, используемой для запуска PHP... это должно быть возможно только для учетной записи администратора /root ).

Если они могут записать файл и быть исполняемым, они могут изменить его на то, что выполняется на вашем компьютере (исполняемый файл или script), а затем использовать PHP shell_exec для запуска этого исполняемого файла. Если вы настроены не разрешать shell_exec, они также могут изменить вашу конфигурацию

Ответ 3

Есть много хороших общих причин следовать минимализму, когда речь заходит о разрешениях, но в контексте веб-хостинга LAMP мало кто приходит на ум:

На общей платформе хостинга другие пользователи, совместно использующие ваш хост, теперь могут читать и писать на ваши скрипты.
На выделенном хосте процессы rouge могут читать/записывать и случайно удалять ваши файлы. Допустим, что в фоновом режиме пользовательский процесс ведения журнала работает как пользователь, у которого есть ошибка, которая приводит к его попытке rm -rf /. Теперь, как правило, это будет безвредно, потому что вряд ли будет файл, на который никто не должен иметь права на запись, но этот процесс румян теперь будет содержать ваши файлы.
Чтобы портить ваш сайт, кто-то должен получить доступ только к любому пользователю, даже сказать никому или какой-либо такой фиктивной учетной записи. Как правило, злоумышленнику придется совершить дополнительную эскалацию на уровне пользователя, чтобы добраться до места, где он может нанести урон. Это реальная угроза. Некоторые некритические службы могут выполняться под фиктивными учетными записями и могут содержать уязвимость.

Ответ 4

Предположим, что на вашем сервере установлен пакет программного обеспечения, и в нем есть уязвимость в нулевой день, злоумышленник получает доступ к вашей панели управления администратора с возможностью загрузки файлов, если вы установите все на 777, для него было бы тривиально загрузить оболочку script где угодно. Однако, если вы правильно установите разрешения, он не сможет этого сделать, так как никто /www -data/etc не будет иметь права на запись.