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

Question

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 tan pocos permisos como sea necesario.

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

Después de todo, un archivo de script PHP se puede ejecutar desde el exterior (es decir,a través de una llamada al servidor web, y posteriormente al intérprete) no importa si está marcado como "ejecutable", ¿no?Y lo mismo se aplica a los archivos llamados a través de la línea de comandos. php intérprete, ¿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 en los que se puede escribir en todo el mundo?

Answer 1

Aquí hay un escenario:

1. Usted tiene un directorio sin protección que los usuarios pueden subir a.
2. Se subir dos archivos:. Un script de shell, y un archivo php que tiene una llamada system() en ella para el script de shell
3. para acceder a las script php que acaba de subir en la siguiente URL en su navegador, haciendo que el script de shell para ejecutar.

Si este directorio es 777, lo que significa que cualquier persona (incluyendo el usuario apache, que es lo script PHP ejecutará como) puede ejecutarlo! Si el bit de ejecución no se encuentra en ese directorio y presumiblemente los archivos dentro del directorio, entonces el paso 3 anterior no haría nada.

edición de los comentarios: no es los permisos del archivo PHP que importa, es la llamada system() dentro del archivo PHP que se ejecuta como una llamada al sistema de Linux por el usuario apache linux (o lo que sea que tenga Apache configurado para ejecutarse como) y que es precisamente donde las cuestiones de bits ejecución.

Answer 2

Se incrementa en gran medida el perfil de vulnerabilidad de su sitio web para actividades maliciosas, ya que sólo es necesario entrar en una cuenta.

Cualquier persona que obtiene acceso a su sistema con cualquier inicio de sesión puede hacer lo que quieran a sus páginas, incluyendo el cambio a leer "Este sitio es muy insegura por lo que por favor, dame la información de su tarjeta de crédito."

EDIT: (Para aclarar y comentarios de direcciones)

Muchos servidores tienen más de un propósito en la vida. Se ejecutan múltiples servicios. Si aísla cuidadosamente esos servicios entre sí mediante la asignación de cada uno de un usuario único y la gestión de los permisos de archivos en consecuencia, sí, usted todavía está en agua caliente si alguien pone en peligro las credenciales de una cuenta, pero el daño que pueden hacer se limita a que un servicio . Si sólo tiene una cuenta genérica y configurar todo el sistema de archivos a 777, una cuenta comprometida pone en peligro todo en la máquina.

Si su servidor se dedica sólo a correr Apache / PHP y no tiene otro propósito en la vida, y sólo hay una cuenta con la que Apache / PHP se está ejecutando, teniendo que una cuenta comprometida es tan bueno como tener toda la máquina comprometida desde el punto de vista de su aplicación (aunque aún debe haber archivos de sistema protegidos y no escrito por la cuenta utilizada para ejecutar PHP ... que todavía sólo debería ser posible para una cuenta de administrador / root).

Si son capaces de escribir un archivo, y es ejecutable, se puede cambiar a algo que se ejecuta en su máquina (ejecutable o script) y luego utilice shell_exec de PHP para ejecutar ese ejecutable. Si está configurado para no permitir shell_exec, pueden cambiar su configuración, así

Answer 3

Hay muchas buenas razones generales a seguir minimalismo cuando se trata de permisos, pero en el contexto de un servicio de hosting LAMP, los pocos que vienen a la mente son

• En una plataforma de alojamiento compartido, otros usuarios que comparten su anfitrión puede ahora leer y escribir en las secuencias de comandos.
• En un host dedicado, procesos rouge pueden leer / escribir, y sin querer borrar sus archivos. Digamos que hay un proceso de registro personalizado ejecuta en segundo plano, ya que nadie de usuario que tiene un error que resulta en que esta tratando de rm -rf /. Ahora por lo general esto será inocua porque no habría apenas ser cualquier archivo que nadie debe tener permisos de escritura en este proceso, pero rouge ahora a tomar sus archivos con él.
• Para desfigurar su sitio web, necesita a alguien que sólo el acceso de ganancia como cualquier usuario, incluso dicen que nadie o algo por cuenta ficticia. En general, el atacante tendría que hacer un ataque de escalada nivel de usuario más para llegar al lugar en el que pueda hacer algún daño. Esta es una amenaza real. Algunos servicios no críticos pueden estar ejecutándose en cuentas ficticias y podrían contener una vulnerabilidad.

Answer 4

Supongamos que haya instalado un paquete de software en el servidor y no hay una vulnerabilidad de día cero en él, el atacante obtiene acceso a su panel de control de administración con capacidades de carga de archivos, si se establece todo para 777 sería trivial para él para cargar un script de shell en cualquier lugar que quiera. Sin embargo, si se configura adecuadamente los permisos que no puede hacerlo ya que nadie / www-data / etc no tendrá permisos de escritura.