Bug crítico en Linux, presente desde hace 5 años
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.
Este fallo podría afectar a un equipo escuchando y se debería ejecutar un binario que explote el fallo en el núcleo. El vector más probable de ataque sería engañar al usuario para que instale un programa malicioso.
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).
Fuente: EtcCrond
Este fallo podría afectar a un equipo escuchando y se debería ejecutar un binario que explote el fallo en el núcleo. El vector más probable de ataque sería engañar al usuario para que instale un programa malicioso.
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).
Fuente: EtcCrond
0 Comments:
Publicar un comentario
Gracias por dejar un comentario en Segu-Info.
Gracias por comentar!