Barrapunto

Imagino que muchos sois los que leéis estos boletines con lo que nada nuevo se aporta con esta entrada, así que haré un barrido general por el asunto a modo introductorio.

¿En qué consiste el fallo?

Los fallos, porque son varios, están todos relacionados con el cargador ELF, que hace honor al acrónimo Executable and Linkable Format, el estándar por excelencia en Linux para gestionar la carga de binarios en detrimento del formato anterior, actualmente obsoleto y en desuso, el formato binario a.out, lo que proporciona ventajas interesantes, como por ejemplo la mejora en la creación de bibliotecas compartidas, soporte de funciones interesantes como dlopen(), dlsym() y dlclose() (funciones que junto a dlerror() proporcionan implementación al cargador dinámico de enlaces), y sobre todo, compatibilidad con las variantes UNIX fundamentadas en System V Release 4 (SVR4).

Los fallos detectados son cinco (5) que paso a citar textualmente:

(a)* Verificación incorrecta del valor de retorno de la función "kernel_read()".

(b)* Gestión incorrecta de errores en caso de fallo en la ejecución de "mmap()".

(c)* Gestión incorrecta de errores en el mapeo en memoria del segmento "interpreter" del ejecutable ELF.

(d)* No se comprueba que el ejecutable ELF contenga un nombre de intérprete terminado correctamente con un byte nulo ("\0").

(e)* Bajo ciertas circunstancias, puede ser posible leer ejecutables ELF sin permiso de lectura, pero sí de ejecución.

Las vulnerabilidades son de amplio espectro y en combinacion podrían desencadenar problemas y serios. La primera (a) consiste en un fallo en kernel_read() que podría provocar que el retorno de la función indicase una cantidad menor de bytes en la petición de tamaño de buffer, lo que podría provocar el retorno de una cantidad negativa de tamaño (condición única especificada en la función).

El caso (b) es relativo a mmap(). Se pueden producir, caso de que falle la llamada a mmap() [típicos en el procesado de secciones binarias en forma de bucles en memoria] comportamientos inadecuados y de error.

El caso (c) narra el posible retorno incorrecto de valor durante el mapeo de interpreter lo que puede desencadenar en gestiones incorrectas del valor, ya que no hay contingencias para estos valores erróneos.

El caso (d) enlaza con el anterior, ya que el segmento cargado (erróneo) puede contener una cadena que no incluya NULL o byte nulo, ya que se da por sentado que el segmento que se recibe es correcto y no se comprueba esa condición, induciendo a errores.

Por último, (e) es un caso complejo donde se narra un error en el código de exec.c, concretamente en la función execve() que permite mediante la apertura de binarios según open_exec() que pese a que carecen de permisos de lectura, sí es posible ejecutarlos. Esto se lograría requiriendo el fichero en el segmento PT_INTERP (segmento empleado para cargar las bibliotecas compartidas necesarias, normalmente /lib/ld-linux.so.1 o bien /lib/ld-linux.so.2, según si el binario enlazado corresponde con V5 de libc de Linux o bien V2 de libc de GNU).

Todos estos fallos, en opinión de Jesús Cea (autor del boletín) podrían desencadenar en problemáticas que abarcan desde la ejecución de código con permisos de administrador o "root" (combiándola con la ejecución de binarios SETUID) hasta la caída del sistema, con lo que hablamos de un asunto serio, a mi juicio extremadamente serio, y que volviendo a citar al autor, al cual suscribo plenamente, Estas vulnerabilidades son más fácilmente explotables en situaciones de alta carga, especialmente alta ocupación de memoria. También hay que señalar que, en mayor o menor medida, afectan a todas las arquitecturas.

¿Soluciones?

La versión 2.4.28 de Linux solventa los problemas descritos. Según se informa en el boletín la rama 2.6 está igualmente afectada, con lo que se recomienda, a la espera de parches oficiales, instalar 2.6.10-rc2 o superior.

Habrá que ver qué repercusiones hay en otras arquitecturas, ya que Linux no es la única afectada, por motivos obvios.

Un salu2 ;)