Bug en la implementación de ext2, ext3 y ext4
December 2, 2007Como todo software diseñado por las personas, el Software libre tampoco se escapa de las vulnerabilidades, o de las características que pueden ser convertidas en vulnerabilidades. Estas son las llamadas features.
Vía eyeIdeas, me entero de la existencia de un error en la implementación de ext2, ext3 y el nuevo ext4 que puede colgar sistemas *nix que usen estos sistemas de archivos.
(Ya que no somos lammers no iremos directamente a la vulnerabilidad en sí misma, sino que primero describiremos en que se basa)
Según el blog, en la Universidad de Eindhoven se lleva un curso llamado “Linux Kernel and Hackers hut” (Kernel Linux y choza de Hackers) dictada por Andrie E. Brouwer, un hacker del Kernel Linux.
(Para los que no sepan, un Hacker del Kernel Linux es una persona que lejos de reventar el Kernel con exploits, se encarga de programar el Kernel y tiene un conocimiento profundo de su funcionamiento).
Este hacker explicaba en sus clases que el sistema de archivos ext2, ext3 y ext4 poseen un bit que si está activado, indica al sistema operativo que debe lanzar un Kernel Panic y detenerse. Es decir, si se lee un sistema de archivos defectuoso debe detenerse a todo el sistema.
Andrie alertó en el 2005 sobre los posibles peligros que esta característica, incluída posiblemente para no dañar sistemas de archivos, podía causar. Sin embargo no se le prestó mucha atención ya que entornos *nix, sólo el root puede montar un sistema de archivos.
Sin embargo, muchas distribuciones Linux como por ejemplo Ubuntu, Fedora, Open SuSe, Mandriva, Debian y demás, usan un sistema de automontaje que monta automáticamente (Por medio de /etc/fstab o algún software) los dispositivos cuando son conectados.
Debido a que el montaje sólo puede ser usado por root, estos sistemas de automontaje actúan con privilegios de root, por lo que se abre una puerta a un atacante para que monte un sistema de archivos defectuoso y provoque la caída de un sistema basado en *nix o que soporte los sistemas de archivos vulnerables.
Para probar si esta vulnerabilidad nos afecta, debemos ejecutar los siguientes comandos. (Suponiendo que tenemos un sistema de archivos de prueba).
(Nota: No me hago responsable por lo que pueda pasar. No debe usarse el comando en entornos de producción).
tune2fs -e panic [Imagen/Dispositivo]
Ya tenemos el bit de Panic activo. Ahora solo queda montarlo con…
mount [Imagen/Dispositivo]
Para ver un Kernel Panic. Si nos arrepentimos, podemos desactivarlo mediante…
tune2fs -e continue [Imagen/Dispositivo]
Esto permitiría llevar una USB especialmente preparada para ir colgando los sistemas *nix que tengamos a nuestro paso. Si tenemos un Sistema de Archivos en Red, también podría activarse el bit fatal y hacer colgar a las PC que se conecten al mismo.
Para los preocupados, se puede decir que pmount (Un programa para montar dispositivos desde un usuario normal) a partir de su versión 0.9.13-4 ya no reconoce el bit fatal para tranquilidad de los usuarios. Sin embargo no todas las distribuciones usan pmount. Ubuntu no la usa así que depende de Cannonical y de la comunidad encontrar una solución a tan apremiante problema.
Una nota para los que crean que con esta información podrán ‘colgar’ un sistema Linux así de fácil. Para explotar el bug deben tener acceso físico a la PC en cuestión, para poder cambiar el bit y montar o para insertar la USB con el bit fatal. Es decir, este artículo ni la vulnerabilidad servirán para que algún script kiddie se haga un script y pueda alardear de colgar sistemas *nix.
Esperemos que las distribuciones que no usen pmount puedan pronto solucionar el problema, por ejemplo haciendo ignorar ese bit.





