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.