Hoy mismo se ha dado a conocer
un
importante fallo de seguridad en el núcleo Linux que afecta a todas las
versiones desde la 2.6.31(¡una versión del 2009!) hasta la actual
3.14.3. Se trata de un fallo que es capaz de corromper la memoria
asignada al núcleo y hasta puede permitir que un usuario no-root pueda
obtener privilegios de autorización. Red Hat afirma que RHEL 6 no es
vulnerable y las distribuciones Fedora y Ubuntu, que tenían acceso por
adelantado al
CVE-2014-0196 desde hace dos semanas, ya han publicado las actualizaciones de
seguridad correspondientes con parches propios.
Debian ha lanzado ya una actualización, pero solo para la rama estable. Sin embargo, el proyecto Linux tan solo ha agregado
el parche a la rama de desarrollo y las demás distribuciones no han movido ficha aún.
El fallo fue descubierto por un usuario de SuSE, la distribución
comercial de Novell. El fallo consiste en que si se da simultáneamente
más de una orden de escritura a la misma pseudoterminal (una TTY), se
puede producir lo que se conoce como un "desbordamiento de búfer" (buffer overflow);
es decir, un intento de escribir más allá de la memoria asignada a una
variable del procedimiento que se está ejecutando en ese momento. Como
el procedimiento que lleva a cabo una orden de escritura en una
pseudoterminal, llamado n_tty_write(), es una función del núcleo Linux, al producirse el desbordamiento, habremos sobreescrito memoria del mismísimo núcleo hasta donde queramos.
¿Por qué es peligroso que se desborde un búfer? Simplemente porque en
ejecutables binarios escritos en C o C++ al final de la memoria de cada
procedimiento se encuentra la dirección de memoria del procedimiento
"padre". Si sobreescribimos esa información con una dirección que
nosotros controlamos, podemos entonces ejecutar código arbitrario. Si
esto se produce, como en este caso, sobreescribiendo la memoria de un
proceso "privilegiado" (el núcleo, un demonio, etc.), el proceso
arbitrario que ejecute el atacante también tendrá privilegios de
administrador, por lo que podrá modificar el sistema a su antojo sin
necesidad de entrar al sistema como "root". Por otro lado, si no se
sobreescribe la memoria con nada significativo y solo se produce el
desbordamiento, entonces el núcleo se caerá y tendremos un "kernel
panic".
Si os fijáis, estoy repitiendo constantemente que se tiene que dar la condición de que se produzca el desbordamiento. Esto se debe porque el fallo sucede en un fenómeno técnicamente conocido como "condición de carrera" (race condition).
Desde hace tiempo existe la posibilidad de ejecutar código en paralelo,
en "hilos" o "procesos" diferentes (no son sinónimos, pero ambos se
refieren a formas de ejecutar órdenes en paralelo). El problema consiste
en que no hay forma de predecir el momento ni el orden en que se
ejecutan los hilos o procesos (de hecho, cuando se programa en paralelo
hay que tener esto muy en cuenta y nunca escribir código paralelizado
que asuma uno u otro orden de ejecución). Por lo tanto, puede suceder
que dos o más hilos o procesos intenten acceder o modificar una misma
región de la memoria, con la consecuencia de obtener un resultado
totalmente impredecible en la ejecución del programa (hay formas de
protegerse de esto que, básicamente, consiste en marcar temporalmente
una variable como "propiedad" de un hilo u otro). En el caso que nos
toca hoy, resulta que dependiendo de la sincronización y del orden en
que acaban ejecutándose las órdenes paralelas de escritura a la TTY,
podemos sufrir el desbordamiento o no.
De hecho, podéis probar esto por vosotros mismos
ejecutando esta prueba de concepto
de explotación de la vulnerabilidad. A mí me produjo una caída del
núcleo tan solo a la tercera vez de ejecutarlo (Arch Linux con 3.14.3
"stock"), pero a la primera y segunda el azar quiso que no tuviera
efecto alguno.
Compiladla y probadla bajo vuestro riesgo (hará caer el sistema si tiene éxito).
A diferencia de la opinión vertida por
los redactores de Ars Technica, que consideran que son los servidores los que más peligro de ser atacados por esta vía,
creo que el peligro real está en Android. El código vulnerable
está presente
(líneas 1997 y ss.) en la última versión del núcleo utilizada por
Android 4.4 (basado en Linux 3.4) y la imposibilidad de actualizar la
mayoría de los dispositivos hace que esto sea un vector de ataque
bastante plausible contra aquellos dispositivos que no se verán
actualizados jamás. La única recomendación posible aquí es que mientras
Google no publique un parche tengáis mucho cuidado en no instalar
aplicaciones sospechosas. Es verdad que las distribuciones Linux de
escritorio que no hayan actualizado su núcleo aún también son
vulnerables, pero si uno se ciñe a los repositorios oficiales, uno
debería quedarse tranquilo (lo único que podría pasar es que, por mala
suerte, el núcleo se cayera por darse las condiciones para el
desbordamiento, pero si no ha pasado aún después de tantos años, es poco
probable que pase).
Este año está siendo un año negro de descubrimiento de errores graves en el Software Libre: primero
el "goto fail" de Apple (sí, era código libre) y el de de GnuTLS, luego
Heartbleed
y ahora este. No quiero dar la sensación de que esta noticia sea una
buen, porque no lo es, pero sí es verdad que alivia ver cómo la
comunidad se mueve para solventar estos fallos una vez descubiertos con
una rapidez que ningún proyecto privativo del tamaño de Linux puede
permitirse.
Recordad que no hay software perfecto, pero sí que hay
proyectos que, al funcionar con libertad, permiten que cualquiera
contribuya y alerte a la "inteligencia colectiva" de que algo está
fallando.
Así que estad atentos a las actualizaciones de
seguridad de vuestra distribución e
instaladlas lo antes posible.
