Introduccion a chroot, ¿Que es? ¿Como funciona?

El comando chroot y la llamada al sistema chroot pueden sonar como una buena medida de seguridad – un comando ejecutado y el comando “cd /” no transporta mas al directorio raiz del sistema. En vez de eso te encuentras atrapado en una parte restringida del sistema de archivos, rodeado solo por unos pocos archivos seleccionados por un administrador de sistemas paranoico. De hecho, asi es como deberia ser.

¿Es posible romper la jaula creada por chroot? Si, si se dan ciertas condiciones.

Primero, ¿como funciona? Cuando uno escribe /sbin/chroot directorio en la linea de comandos de un sistema UNIX uno ve que el directorio raiz pasa a ser ‘directorio’ (el comando /bin/ls / ahora lista los archivos contenidos en ‘directorio’ en caso de que tengas el comando ‘ls’ hubicado en dentro del nuevo directorio raiz). El comando del shell chroot cambia el directorio raiz para un proceso, entra en el directorio ey luego inicia un shell o un comando especifico de un usuario.

El comando chroot usa la llamada del sistema chroot(). El comando y la llamada al sistema tienen una importante diferencia entre ellos: a diferencia del comando, la llamada chroot() no cambia el directorio de trabajo actual al nuevo dentro de la jaula. El codigo de chroot.c muestra la siguiente secuencia de llamadas al sistema:

Code:
chroot (argv[1]);
chdir ("/");

Como se vera mas adelante, esto permite romper la jaula facilmente.

Chroot es comunmente usado como medida de seguridad. Si alguna vez has usado un servidor de ftp anonimo, has estado en una jaula chroot. El servidor Ftp se enjaula a si mismo dentro de un directorio especial para los usuarios anonimos. El demonio bind encargado del DNS (Domain Name System) suele ser enjaulado tambien. Tambien se sugiere enjaular los shell remotos telnet y ssh dentro del correspondiente directorio home del usuario, de forma que solo puedan actualizar su pagina web. Los servidores Web tambien pueden ser enjaulados. Cuando chroot esta implementado, los programas que corren dentro de la jaula no pueden acceder a ningun recurso del sistema fuera de la jaula. Esto quiere decir que todas las librerias del sistema, archivos de configuracion e incluso los dispositivos deben ser creados dentro de la jaula.

¿Que demonios pueden ser enjaulados? Si un demonio tiene acceso a archivos que no son faciles de recolectar en un sitio, enjaularlo puede ser dificil. Por ejemplo, sendmail necesita /var/spool/mail, otros archivos de ahi como ser mqueue, el directorio home de los usuarios (para revisar el archivo .forward) y archivos de configuracion del sistema en /etc. No hay lugar del sistema de archivos donde sendmail pueda ser efectivamente confinado. Si las funciones de sendmail se separan en el demonio de spool y el MTA entonces es completamente posible enjaularlo.

Enjaular el shell de un usuario es posible si se necesita mantenerlo en un directorio en particular. Sugerencias de como hacer esto con ssh2 se encuentran en las FAQ de ssh, y para OpenSSH en los archivos de Linux From Scratch. Sin embargo, esto involucra copiar multiples librerias del sistema, archivos y multiples recursos como Linux Pluggable Authentication Modules (PAM), usado por las distribuciones modernas de GNU/Linux.

Cualquier cosa ademas de bind, apache, squid puede ser enjaulada, pero a veces el beneficio no es claro, especialmente para los demonios que se ejecutan como root.

“¿Que demonio deberia ser enjaulado?” es una pregunta completamente distinta de “¿Que demonio puede ser enjaulado?” Antes de responder eso, analicemos como un atacante puede romper la jaula chroot.

Primero, cuanto mas software este dentro del entorno chroot, mas peligroso es, ya que se vuelve dificil rastrear que programas pueden ser usados por un atacante para elevar permisos y escapar.

Segundo, la cantidad de formas de que el usuario root puede romper la jaula es enorme. Empezando por simplemente usar la llamada chroot() sin la llamada chdir() [ver codigo abajo] hasta metodos como crear tu propios dispositivos /dev/hda o /dev/kmem, inyectar codigo dentro del kernel en ejecucion. Mientras que las capacidades del sistema pueden ser usadas para dejar inoperativos muchos de esos metodos, siempre hay atacantes astutos que encuentran nuevos.

Code:

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>

int main (void) {
   mkdir("breakout", 0700);
   chroot("breakout");
   for (int i = 0; i < 100; i++) {
      chdir("..");
   } // for
   chroot(".");
   execl("/bin/sh", "/bin/sh", NULL);
} // main

compilado estaticamente (usando “gcc -static”) y ejecutandolo dentro de la jaula chroot (despues haciendo “chroot .” o similar desde el shell) para escapar.

Tercero, si no hay definido un usuario root, binarios SUID o dispositivos dentro del entorno chroot, no SUID binaries, no devices, y el demonio mismo no da privilegios de root despues de llamar a chroot() (como el codigo abajo), romper la jaula parece ser imposible. En otras palabras, si no hay forma de ganar un shell de root o ejecutar acciones que solo el root pueda hacer (ej. crear dispositivos, o acceder memoria raw) romper la jaula no es posible. Idealmente, si un programa usa chroot por razones de seguridad, la secuencia de llamadas deberia ser:

Code:
chdir("/home/safedir");
chroot("/home/safedir");
setuid(500);

Hay que tener en mente que despues de que esas lineas son ejecutadas no habra forma de que el programa obtenga privilegios de root.

Cuarto, en algunos casos los atacantes pueden no ser capaces de romper la jaula (es decir correr procesos fuera del directorio), pero en vez de eso pueden ser capaces de afectar los procesos de alguna forma. Por ejemplo, si bind esta enjaulado, varios dispositivos deben ser creados. Uno de ellos es /dev/log, necesario para registrar los mensajes de bind en los log regulares del sistema. Creando un malicioso mensaje de log y enviandolo a /dev/log desde la jaula un atacante puede influenciar el comportamiento del demonio syslog que corre fuera de la jaula. Si hay un desbordamiento de buffer en syslog (que corre como root) se pueden obtener privilegios adicionales.

¿Que demonios pueden ser enjaulados pero sin valor para la seguridad? viendo lo anterior, enjaular programas que puedan dar privilegios de root no provee mucha seguridad extra.

Para concluir, chroot() es una buena manera de incrementar la seguridad del software. Enjaular programas previene a un atacante de leer archivos fuera de la jaula y previene ataques locales como abuso de SUID y /tmp.

=-=-=-=-=
Powered by Blogilo

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s


A %d blogueros les gusta esto: