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

lamp server ubuntu (4)

Aquí hay un escenario:

Tienes un directorio desprotegido en el que los usuarios pueden cargar.
Cargan dos archivos: un script de shell y un archivo php que tiene un system() llamado al script de shell.
acceden al script php que acaban de subir 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 ejecutará el script php) ¡puede ejecutarlo! Si el bit de ejecución no está establecido en ese directorio y presumiblemente en 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 la llamada al system() dentro del archivo PHP que se ejecutará como una llamada al sistema Linux por el usuario de Linux apache (o lo que sea que apache configure para ejecutarse como), y eso es PRECISAMENTE donde importa el bit de ejecución.

Inspirado por la discusión en esta pregunta , una pregunta tal vez estúpida.

A todos nos han enseñado que dejar directorios o archivos en un alojamiento web basado en Linux con el nivel de permiso de 777 es algo malo, y establecer siempre los permisos mínimos que sean necesarios.

Ahora tengo curiosidad sobre dónde reside exactamente el peligro de explotación, específicamente en un contexto PHP / Apache.

Después de todo, un archivo de script PHP puede ejecutarse desde el exterior (es decir, a través de una llamada al servidor web y, posteriormente, al intérprete) sin importar si está marcado como "ejecutable", ¿no? Y lo mismo se aplica a los archivos llamados a través del intérprete php línea de comandos, ¿verdad?

Entonces, ¿dónde está exactamente la vulnerabilidad con 777 ? ¿Es el hecho de que otros usuarios en la misma máquina pueden acceder a archivos que se pueden escribir en todo el mundo?

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

Cualquier persona 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 diga "Este sitio web es realmente inseguro, así que por favor proporcione 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. Ellos ejecutan múltiples servicios. Si aisla cuidadosamente esos servicios el uno del otro asignando a cada uno un usuario único y administrando los permisos del archivo en consecuencia, sí, todavía está en peligro si alguien compromete las credenciales de una cuenta, pero el daño que pueden hacer 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 únicamente a ejecutar Apache / PHP y no tiene otra finalidad en la vida, y solo hay una cuenta bajo la cual Apache / PHP se está ejecutando, tener esa única cuenta comprometida es tan buena como tener toda la máquina comprometida desde el punto de vista de su aplicación (aunque todavía debería tener archivos del sistema protegidos y no modificables por la cuenta utilizada para ejecutar PHP ... que aún debería ser posible solo 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 script) y luego usar el shell_exec de PHP para ejecutar ese ejecutable. Si está configurado para no permitir shell_exec, también pueden cambiar su configuración

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

En una plataforma de alojamiento compartido, otros usuarios que comparten su host ahora pueden leer y escribir en sus scripts.
En un host dedicado, los procesos de rouge pueden leer / escribir y borrar accidentalmente sus archivos. Digamos que hay un proceso de registro personalizado ejecutándose en segundo plano como usuario nobody, que tiene un error que hace que trate de rm -rf / . Ahora, en general, esto será inofensivo porque difícilmente habría ningún archivo en el que nadie debería tener permisos de escritura, pero este proceso de rouge ahora llevará sus archivos.
Para desfigurar su sitio web, alguien solo tiene que obtener acceso como cualquier usuario, incluso decir nadie o alguna de esas cuentas ficticias. En general, el atacante tendría que realizar un nuevo ataque de escalamiento del nivel de usuario para llegar al lugar donde puede hacer algo de daño. Esta es una amenaza real. Algunos servicios no críticos se pueden ejecutar bajo cuentas ficticias y pueden contener una vulnerabilidad.

Supongamos que tiene un paquete de software instalado en su servidor y tiene una vulnerabilidad de día cero, el atacante obtiene acceso a su Panel de control de administración con capacidades de carga de archivos, si configura todo en 777 sería trivial que cargue una guión de shell en cualquier lugar que quiera. Sin embargo, si configura los permisos correctamente, no puede hacerlo ya que nadie / www-data / etc no tendrá permisos de escritura.