¿La mayoría de los sistemas Linux que permiten que los usuarios que no son root ejecuten el código directamente como rooteados?

63
  

En pocas palabras, si puede ejecutar código en un cuadro, normalmente es sencillo obtener la raíz

( fuente de cita )

La implicación inmediata de esta cita (si es precisa) es que si está ejecutando un sistema multiusuario y no hace todo lo posible para evitar que todos los usuarios creen archivos con el conjunto de permisos x , el sistema es tan bueno como comprometido. El corolario es que el funcionamiento de un sistema multiusuario, como los que normalmente se encuentran en las universidades, que por diseño les permite a todos los estudiantes hacer ejercicios en C, C ++, ensamblaje, etc., es inútil, ya que cualquier estudiante puede enraizar directamente este sistema. p>

Dado que la ejecución de sistemas informáticos destinados a ser utilizados por más personas que sus propietarios no se considera inútil, y las instalaciones limitadoras de privilegios (gestión de derechos de los usuarios, sandboxing, etc.) no se consideran inútiles, de alguna manera dudo de este tipo de comentarios. Pero, ¿qué sé yo?

¿Es cierto que la mayoría de los sistemas Linux pueden ser rooteados directamente por cualquiera que pueda ejecutar código en ellos?

    
pregunta gaazkam 29.10.2018 - 23:52
fuente

4 respuestas

90

No, esto no es correcto. Si bien uno puede discutir la dificultad relativa de encontrar y explotar las vulnerabilidades de 0 días en Linux cuando tiene acceso local, la arquitectura de seguridad de un sistema Linux moderno (con una MMU) está diseñada para aislar a diferentes usuarios y evitar la escalada de privilegios. Un usuario no root no puede obtener root sin la autorización adecuada sin explotar una vulnerabilidad existente, y esas vulnerabilidades de escalada de privilegios se parchean muy rápidamente tan pronto como se descubren. *

Sin embargo, es posible abusar del factor humano y obtener la raíz mediante la explotación de conceptos erróneos ubicuos en la profesión de administrador de sistemas. Esto, por supuesto, se basa en que el administrador del sistema malinterpreta la arquitectura de seguridad del sistema que mantienen. Una lista no exhaustiva de ejemplos:

  • Elevar privilegios con sudo o su de un usuario no privilegiado pero no confiable. 1

  • Engañar a un administrador del sistema para que ejecute ldd en un ejecutable estático malicioso como root. 2

  • Abusando de un binario instalado de forma insegura. 3

  • Desplegándose a un usuario menor desde la raíz, lo que permite un ataque de rechazo TTY. 4 5

* Si bien esto es ostensiblemente cierto, muchas implementaciones no se actualizan con la frecuencia suficiente, lo que hace que los sistemas de producción en vivo sean vulnerables a errores conocidos. Una actualización disponible no garantiza que se instale una actualización.

    
respondido por el forest 30.10.2018 - 00:05
fuente
26

Para volver a redactar la cita: existen vulnerabilidades de escalamiento de privilegios que se seguirán encontrando o creando.

Durante la última semana, tenemos esta pequeña euforia en SystemD ; ¿Qué vamos a tener la próxima semana? ¿Se arreglará a tiempo y qué tan bueno es su régimen de parches?

Debería suponer que es factible que un atacante que puede ejecutarse en un cuadro probablemente pueda obtener acceso de root a su instancia de SO en algún momento, independientemente de qué sistema operativo esté en juego. La "simple" tarea tal es quizás discutible, pero si un usuario puede ejecutar un código arbitrario, entonces tiene un amplio margen de acción.

    
respondido por el James Snell 30.10.2018 - 12:54
fuente
14

Explotar una vulnerabilidad de escalada de privilegios ya es lo suficientemente difícil, hacerlo al mismo tiempo que te aseguras de no dejar rastro es mucho más difícil. Un usuario de Android que intente rootear su teléfono puede seguir intentando explotar uno tras otro, sin preocuparse o tener que ocultar sus huellas. Un estudiante que intente abusar repetidamente de sudo o la distribución de archivos ejecutables a través del recurso compartido de archivos probablemente será advertido y reprendido o expulsado.

Por cierto, la principal forma de obtener acceso de root en una configuración multiusuario es esperar hasta que un usuario privilegiado salga de la estación de trabajo y se olvide de bloquearla. Lo he visto en dos de las tres universidades a las que asistí. Sin embargo, se aplica el mismo comentario sobre no ser atrapado.

    
respondido por el Dmitry Grigoryev 30.10.2018 - 14:59
fuente
5

Creo que "directamente" significa "sin trucos humanos ni otra ingeniería social". Entonces, la respuesta es: sí, si los sistemas contienen 0 días sin parches que llevan a una escalada de privilegios.

Podría ser un nivel de aplicación de 0 días. Por ejemplo, si hay ejecutables propiedad de root con permisos setuid que podrían afectar a archivos arbitrarios. La última referencia es Xorg . Puedes buscar posibles vectores como este: find / -user root -perm -4000 -print 2>/dev/null . Otro ejemplo: servicio de sistema como systemd mencionado anteriormente.

O podría ser un nivel de kernel de 0 días. Son bastante más raros pero más ruidosos porque su cobertura es mucho más amplia. Una buena referencia es dirty COW .

Lo anterior es cierto si hay una ausencia de Controles de acceso obligatorios habilitados que pueden evitar la ejecución de algunas hazañas.

O ot podría ser incluso un ataque de nivel de arranque. Arranque seguro es tu amigo entonces.

    
respondido por el odo 31.10.2018 - 16:30
fuente

Lea otras preguntas en las etiquetas