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

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

РЕДАКТИРОВАТЬ: (Для уточнения и адресации комментариев)

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

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

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

Answer 3

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

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

Answer 4

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