SELinux bloqueó proactivamente el bug /proc del kernel Linux
El otro día publicamos en una-al-día una nota, en la que reflejábamos la gravedad de un problema recientemente diagnosticado en ciertas versiones del núcleo Linux.
El problema, existente en la rama 2.6 y cocnretamente en las versiones inferiores a la 2.6.17.4, permitía, mediante un sencillo exploit publicado on the wild, a modo de 0day, escalar privilegios en máquinas Linux.
Pues bien. No todos los kernels teóricamente vulnerables terminaron siéndolo. Sirva el ejemplo de seguridad proactiva de Security Enhanced Linux, SELinux, sobre el que habla James Morris en su blog. Referencias adicionales sobre este tema pueden ser consultadas, por ejemplo, en el ISC de SANS, que confirma la inexpugnabilidad de SELinux:
SELinux blocks CVE-2006-3626 (local privilege escalation)
Joshua Brindle has analyzed the recent /proc local privilege escalation vulnerability, CVE-2006-3626, and posted that SELinux targeted policy prevents exploitation.
It'd be an interesting and useful exercise to go back through historical vulnerabilities and determine how many of them would be mitigated by SELinux and similar technologies (Exec-shield, PIE etc.).
Mark Cox wrote an interesting paper, Risk Report: A year of Red Hat Enterprise Linux 4, which mentions that SELinux blocked the Lupper worm (also noting that that the policy version shipped by default would not have blocked a modified version of the worm).
La culpa de esta proactividad la tiene SELinux targeted policy, única en su especie. Este modo de ejecución permite al administrador confinar ciertos procesos críticos bajo el gobierno directo de esta targeted policy, mientras que el resto de procesos quedan bajo la tutela de la seguridad genérica de un sistema GNU/Linux, en el dominio unconfined_t.
Los demonios supervisados por esta política son, habitualmente, dhcpd, httpd (apache.te), named, nscd, ntpd, portmap, snmpd, squid, y syslogd. Toda la información sobre demonios protegidos está en /etc/selinux/targeted/src/policy/domains/program.
Observad la diferencia entre un Setenforce puesto a 0, y a 1:
Setenforce 0
[jbrindle rhel4-dev ~]$ id
uid=501(jbrindle) gid=502(jbrindle) groups=502(jbrindle)
context=user_u:system_r:unconfined_t
[jbrindle rhel4-dev ~]$ ./h00lyshit /bin/ash.staticpreparing
trying to exploit /bin/ash.staticsh-3.00# id
uid=0(root) gid=502(jbrindle) groups=502(jbrindle)
context=user_u:system_r:unconfined_t(may take a few times to get since it's a race, clear your cache between
tries)Setenforce 1
[jbrindle rhel4-dev ~]$ ./h00lyshit /bin/ash.static
preparing
trying to exploit /bin/ash.staticfailed: Permission denied
All related denials:
audit(1152957171.464:5): avc: denied { setattr } for pid=6291
comm="h00lyshit" name="environ" dev=proc ino=412286986
scontext=user_u:system_r:unconfined_t
tcontext=user_u:system_r:unconfined_t tclass=file
audit(1152957171.465:6): avc: denied { execute } for pid=6292
comm="h00lyshit" name="environ" dev=proc ino=412286986
scontext=user_u:system_r:unconfined_t
tcontext=user_u:system_r:unconfined_t tclass=file
audit(1152957171.467:7): avc: denied { execute_no_trans } for
pid=6292 comm="h00lyshit" name="environ" dev=proc ino=412286986
scontext=user_u:system_r:unconfined_t
tcontext=user_u:system_r:unconfined_t tclass=file
Así se comporta un sistema operativo seguro ante un incidente desconocido. ¿Te gusta el concepto? ¿Quieres algo así para tu casa, tu oficina o para tu red corporativa?
Descárgatelo. Es gratis.
Trackbacks & Pingbacks
[...] La primera razón es la económica. En Extremadura desarrollan gnuLinEx, un conjunto de herramientas libres de diverso propósito, como un sistema operativo completamente funcional que incluye un entorno de escritorio gráfico, una suite ofimática — procesador de textos, hoja de cálculo, presentaciones, base de datos, etc. — , software de contabilidad, facturación, etc., apoyándose en productos ya existentes o creando productos nuevos, dando como resultado un todo seguro, gratis, libre y abierto. [...]
[...] Ahora como funciona? SE Linux funciona como un modulo en el núcleo. Dando un nivel de abstracción mas alto. Recuerden que la seguridad clásica de *nix es por niveles de usuarios, grupos y derechos de accesos. Donde un usuario puede ejecutar una aplicación a la que tiene derechos y la aplicación se ejecuta con los niveles de acceso que tiene el usuario. Este tipo de seguridad se denomina DAC (Discretionary Access Control). La NSA introdujo un sistema de control tipo MAC (Mandatory Access Control) basado en contextos donde se indica cuando un objeto puede acceder a otro objeto. En este caso el administrador debe definir los derechos para cada usuario que acceda a una aplicaciones que acceda a cualquier objeto del sistema. Para evitar que esta operación sea tediosa se definen roles (Role-Based Access Control,RBAC). Por ejemplo al usuario A le damos derechos para acceder para leer y escribir en los archivos del programa xx, ahora el usuario B solamente necesita lectura y nada mas sobre los mismos archivos. SE Linux funciona como un proceso servidor que se ejecuta como parte del núcleo y evalúa si algo (un proceso o un usuario) dispone de permisos para acceder a un objeto (archivo, dispositivo, etc.). Este mecanismo de control se denomina Type Enforcement (TE). Vamos a suponer que alguien intenta correr un buffer overflow para lograr una escalada de privilegios sobre el programa X, el atacante sólo podrá acceder a los archivos para los cuales el proceso vulnerable esté autorizado por la polÃtica del sistema. El atacante NO logrará el control de TODO el sistema. Un ejemplo mas reciente pueden encontrar en el siguiente link, donde se demuestra como SE Linux impidió una escalada de privilegios en la rama 2.6.17: http://www.sahw.com/wp/archivos/2006/07/23/selinux-bloqueo-proactivamente-el-bug-proc-del-kernel-linux/ [...]
Comentarios
Escribir un comentario
Las rupturas de línea y párrafo son automáticas. El e-mail nunca será mostrado ni cedido a terceros. Se permite el siguiente código HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Es por razones como éstas por las que no comprendo muy bien como Windows está certificado EAL-4 y otros sistemas operativos más seguros y mejor diseñados no, o están certificados en un nivel inferior.
Los mecanismos de seguridad mandatoria son, a día de hoy, más que una realidad en los sistemas UNIX (Trusted Solaris, FreeBSD, Linux, OpenBSD), pero ciencia ficción en la “segura” plataforma de Microsoft.
Ah, pues es muy sencillo hombre. Me cito a mí mismo ;)
La clave de EAL está en que se certifica lo que el fabricante asegura cumplir, no un estándar que mida a todos por el mismo rasero. Consecuencia de esto, al menos para mí, la certificación EAL no vale para comparar sistemas, y muchísimo menos, para comparar su seguridad.