En un contexto de PHP/Apache/Linux, ¿por qué exactamente es peligroso chmod 777?

Hay muchas buenas razones generales para seguir el minimalismo cuando se trata de permisos, pero en el contexto de un servidor web LAMP, las pocas que vienen a la mente son

• En una plataforma de hospedaje compartido, otros usuarios que comparten su hospedaje ahora pueden leer y escribir en sus scripts.
• En un host dedicado, los procesos no autorizados pueden leer/escribir y eliminar accidentalmente sus archivos. Digamos que hay un proceso de registro personalizado ejecutándose en segundo plano como usuario none que tiene un error que hace que intente rm -rf / . Ahora, en general, esto será inofensivo porque casi no habrá ningún archivo en el que nadie deba tener permisos de escritura, pero este proceso deshonesto ahora se llevará sus archivos con él.
• Para desfigurar su sitio web, alguien solo necesita obtener acceso como cualquier usuario, incluso decir nobody o alguna cuenta ficticia. Por lo general, el atacante tendría que realizar otro ataque de escalada de nivel de usuario para llegar al lugar donde puede causar algún daño. Esta es una amenaza real. Algunos servicios no críticos pueden estar ejecutándose con cuentas ficticias y pueden contener una vulnerabilidad.

Aumenta considerablemente el perfil de vulnerabilidad de su sitio web a la actividad maliciosa porque solo es necesario entrar en una cuenta.

Cualquiera que obtenga acceso a su sistema con cualquier inicio de sesión puede hacer lo que quiera con sus páginas, incluso cambiarlas para que digan "Este sitio web es realmente inseguro, así que por favor deme la información de su tarjeta de crédito".

EDITAR:(Para aclarar y abordar los comentarios)

Muchos servidores tienen más de un propósito en la vida. Ejecutan múltiples servicios. Si aísla cuidadosamente esos servicios entre sí asignando a cada uno un usuario único y administrando los permisos de archivo en consecuencia, sí, todavía está en problemas si alguien compromete las credenciales de una cuenta, pero el daño que pueden causar se limita a ese servicio. . Si solo tiene una cuenta genérica y configura todo el sistema de archivos en 777, una cuenta comprometida pone en peligro todo en la máquina.

Si su servidor está dedicado solo a ejecutar Apache/PHP y no tiene otro propósito en la vida, y solo hay una cuenta bajo la cual se ejecuta Apache/PHP, tener esa cuenta comprometida es tan bueno como tener toda la máquina comprometida desde el desde el punto de vista de su aplicación (aunque aún debe tener los archivos del sistema protegidos y no escribibles por la cuenta utilizada para ejecutar PHP... eso solo debería ser posible para una cuenta de administrador/raíz).

Si pueden escribir un archivo y es ejecutable, pueden cambiarlo a algo que se ejecute en su máquina (ejecutable o secuencia de comandos) y luego usar shell_exec de PHP para ejecutar ese ejecutable. Si está configurado para no permitir shell_exec, también pueden cambiar su configuración

Aquí hay un escenario:

1. Tiene un directorio desprotegido al que los usuarios pueden cargar.
2. Suben dos archivos:un script de shell y un archivo php que tiene un system() llámelo al script de shell.
3. acceden al script php que acaban de cargar visitando la URL en su navegador, lo que hace que se ejecute el script de shell.

Si este directorio es 777, eso significa que cualquiera (incluido el usuario apache, que es como se ejecutará el script php) puede ejecutarlo. Si el bit de ejecución no está configurado en ese directorio y presumiblemente los archivos dentro del directorio, entonces el paso 3 anterior no haría nada.

editar de los comentarios:no son los permisos del archivo PHP lo que importa, es el system() llame dentro del archivo PHP que se ejecutará como una llamada del sistema Linux por parte del usuario de Linux apache (o lo que sea que apache haya configurado para ejecutarse), y ahí es PRECISAMENTE donde importa el bit de ejecución.