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

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

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

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

В конце концов, файл сценария PHP может выполняться извне (т. Е. Посредством вызова веб-сервера, а затем и интерпретатора) независимо от того, помечен ли он как «исполняемый файл», не так ли? И то же самое относится к файлам, вызываемым через интерпретатор php командной строки, не так ли?

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

Вот один из сценариев:

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

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

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

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

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

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

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

EDIT: (Чтобы уточнить и рассмотреть комментарии)

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

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

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

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