chroot

Últimamente, tras ciertos problemas con las jaulas chroot en linux, me puse a investigar un poco, y la verdad es que me sorprendió lo rápido que encontré información acerca de “problemas” de seguridad al usar esta herramienta, y entrecomillo lo de problemas porque éstos están perfectamente documentados y realmente la herramienta trabaja como debe hacerlo. Primero de todo, para situarnos en contexto: chroot.

Yo siempre había usado chroot como herramienta de seguridad, como una capa más (nunca como única medida, por supuesto) para evitar que un servicio comprometido ponga en peligro a todo el sistema. Cual es mi sorpresa cuando en multitud de páginas encuentro que si se obtienen permisos de superusuario en la jaula, se puede salir de ella forma trivial. La siguiente frase es lapidaria: “Ability to chroot() implies the ability to break out of it”. Esto no es baladí: si se compromete, por ejemplo, un servidor BIND en una jaula y se consigue el usuario named, y tras esto se aprovecha una escalada de privilegios y el atacante consigue convertirse en superusuario, ya dispone de acceso a todo nuestro sistema, no solo a nuestra jaula. En esta pagina podemos ver varios ejemplos de como salir de una jaula, todos ellos muy simples: Secure chroot.

Como resumen, se puede conseguir acceso al sistema padre de tres formas:

  • Creando un directorio temporal y realizando chroot sobre él, si la llamada al original se realizó desde fuera del propio chroot
  • Utilizando múltiples veces la orden chdir(“..”)
  • Utilizando un descriptor de fichero abierto antes de realizar la primera llamada a chroot

Esto hace que exista poca diferencia entre enjaular o no un proceso, ya que con el usuario named, en un sistema sin enjaular, tampoco se podría hacer mucho. Es más, dado que la orden chroot() tan solo restringe a nivel de ficheros, el atacante dispone de nuestra red como si estuviera en el sistema base. El propio Alan Cox, tras una petición de BUG por semejante comportamiento, contesto: chroot is not and never has been a security tool. People have built things based upon the properties of chroot but extended (BSD jails, Linux vserver) but they are quite different.

Tal vez el problema es que muchos administradores usamos chroot pensando que efectivamente, funciona como los jails de BSD o los v-servers de linux, cuando esto no es así. El problema se agrava si además se utilizan herramientas como debootstrap, las cuales crean un entorno base, con las mismas herramientas y librerías que un sistema normal. Esto, que hace muy cómodo el crear un jaula, aumenta el peligro pues existen muchos más vectores de ataque para conseguir una escalada de privilegios una vez comprometido el servicio. Existen multitud de guías para minimizar estos problemas, como por ejemplo: chroot practices. A nivel general, se recomienda:

  • Comprobar que todos los descriptores de ficheros están cerrados cuando invocamos a chroot().
  • Copiar lo mínimo imprescindible para el funcionamiento de la jaula. Con ldd, lsof y revisando /proc podemos averiguar lo mínimo que necesita un servicio para funcionar.
  • NO montar /proc ni /dev con la orden mount –bind, pues el atacante tendrá entonces acceso automático a nuestro sistema.
  • Evitar, dentro de la medida de lo posible, cualquier forma/orden de cambio de usuario nominal a root.
  • Revisar todos los permisos dentro de la jaula, haciendo que el usuario root sea dueño de todos los ficheros posibles y eliminar cualquier permiso no necesario.

Tras todo esto, a los que utilizáis jaulas en Linux para añadir seguridad a ciertos servicios, y si como yo no estábais al corriente de alguno de los comportamientos descritos, recomendaros su revisión, pues la falsa sensación de seguridad es uno de las mayores problemas a los que tiene que enfrentarse un sysadmin.

Comments

  1. Al hilo de este post, creo que puede ser interesante echar un vistazo a la siguiente entrada: http://diegocg.blogspot.com/2011/04/novedades-en-systemd-iii.html

    Un saludo

  2. Ciertamente, fue de dicho blog (el cual sigo asiduamente) donde encontre la entrada de kerneltrap con las declaraciones de Alan Cox. Muy recomendable, ya no la entrada, si no el todo el tabajo de Diego Calleja.

    Saludos.

  3. Supongo que el articulo estará escrito a titulo informativo para gente que desconoce sistemas linux, si es así, este articulo no está mal del todo… pero al leerlo me ha venido a la cabeza «Este articulo es de primero de seguridad, ¿que hace aquí?».

    Un saludo y buenas fiestas.

  4. Olopez, no hace falta que sea para gente que desconoce Linux. Estoy seguro de que hay no pocos administradores de sistemas Linux que utilizan chroot como herramienta de seguridad. Evidentemente, en el plano específico de la seguridad, es probable que mucha más gente conozca este «problema», pero nuestros lectores son muy heterogéneos :)

Trackbacks

  1. […] chroot Últimamente, tras ciertos problemas con las jaulas chroot en linux, me puse a investigar un poco, y la verdad es que me sorprendió lo rápido que encontré información acerca de “problemas” de seguridad al usar esta herramienta, y entrecomillo lo de problemas porque éstos están perfectamente documentados y realmente la herramienta trabaja como debe hacerlo. Primero de todo, para situarnos en contexto chroot. […]

  2. […] obtener mas información de chroot aquí. También teneis un cheat sheet de MySQL muy útil para estas tareas […]

  3. […] Podeis obtener mas información de chroot aquí. […]