Algunos días no llueve, diluvia. Este es el caso de Linux en la actualidad.
Recientemente se han descubierto no uno, sino dos graves agujeros de seguridad. Primero, hubo un error de systemd que fácilmente podía dejar fuera de servicio al sistemas.
Ahora, aparece un agujero de seguridad en el sistema de archivos del kernel de Linux con el que cualquier usuario podría hacerse cargo de todo el sistema.
El equipo de investigación de Qualys, descubrió el error en el sistema de archivos, y también descubrió una vulnerabilidad de conversión de tipo size_t-to-int en el sistema de archivos del kernel de Linux.
Este agujero de seguridad de Linux se ha denominado **Sequoia y fue designado con el identificador CVE-2021-33909.
La gravedad del agujero de seguridad
Quizás, no pareciese esto algo demasiado grave, pero la realidad es que puede usarse contra la mayoría de las distribuciones de Linux en sus configuraciones predeterminadas y lo que es peor, cualquier usuario sin privilegios podría abusar de el agujero para obtener privilegios de root.
¿Cómo funciona Sequoia?
Usamos los sistemas de archivos todos los días, pero probablemente no pienses en cómo funcionan. ¿Quién, excepto los desarrolladores, lo hace?
En el caso de Linux, la interfaz del sistema de archivos se implementa sobre una arquitectura de tres capas; está la capa de interfaz de usuario, la implementación del sistema de archivos y los controladores del dispositivo de almacenamiento.
Dentro de la interfaz seq_file del kernel de Linux se producen archivos virtuales que contienen secuencias de registros y cada registro debe caber en un búfer seq_file. Cuando se queda sin espacio ese búfer, simplemente se agranda duplicando el tamaño.
Eso en sí, no es un problema; puesto que te quedarás sin memoria mucho antes de que puedas hackear el sistema.
El problema aparece cuando esa variable size_t también se pasa a funciones cuyo argumento de tamaño es un entero de 32 bits con signo, no un size_t y eso, puede ser invadido.
Luego, como explica Bharat Jogi (el gerente sénior de vulnerabilidades y firmas de Qualys) “si un atacante local sin privilegios crea, monta y elimina una estructura de directorio profunda cuya longitud total de ruta excede 1 GB y el atacante abre y lee /proc/self/mountinfo para luego usar otra serie de maniobras en las que se puede escribir fuera de los límites de la memoria.
Con eso, se pueden corromper los datos, bloquear el sistema o lo peor de todo, ejecutar código no autorizado; por desgracia, existen numerosos hacks conocidos que utilizan la memoria excesiva para convertirse en el usuario root y tomar el control de una computadora.
De hecho, eso es exactamente lo que hizo el equipo de seguridad de Qualys.
¿Qué sistemas han logrado atacar?
Desde Qualys lograron desarrollar un exploit, que luego fueron capaces de utilizar para obtener privilegios de root completos ante las instalaciones predeterminadas de Ubuntu 20.04, Ubuntu 20.10, Ubuntu 21.04, Debian 11 y Fedora 34.
Si tenemos en cuenta que gran número de distros se basan en estas como raíz, podríamos estar hablando de prácticamente cualquier distribución de Linux es vulnerable a este hack.
La buena noticia es que, si bien este problema sigue vivo en cualquier sistema que ejecute el kernel de Linux 3.16 a 5.13.x o anterior a la versión 5.13.4, ya existen parches disponibles.
De hecho, se supone que el problema se arregla con los últimos parches del kernel.
Parche para Sequoia
Eric Sandeen, el principal desarrollador de sistemas de archivos de Red Hat, encontró una solución para el problema.
Greg Kroah-Hartman, el mantenedor del kernel de Linux para la rama estable de Linux, posteriormente lanzó el parche del kernel para Sequoia el 20 de Julio en la versión 5.13.4 del kernel de Linux.
Si no puede actualizar el kernel, aún puedes mitigar el problema configurando /proc/sys/kernel/unprivileged_userns_clone a 0. Eso evitará que un atacante pueda montar un directorio largo en el espacio de nombres de usuario.
Sin embargo, es posible que el atacante aún pueda montar un directorio venenosamente largo a través del sistema de archivos en el espacio de usuario (FUSE) .
Además, debes configurar /proc/sys/kernel/unprivileged_bpf_disabled a 1 y eso evitará que un atacante cargue un programa eBPF en el kernel.
Sin embargo, puede existir otras formas de atacar el agujero de seguridad, la única forma segura de detener el problema es actualizar el kernel.
Actualmente, la solución está disponible para la mayoría de las distribuciones de Linux, a si que es hora de poner en práctica los comandos de parcheo.
¿Cómo conocer tu versión de kernel?
Puedes conocer la versión de tu kernel en un sistema de Linux, con cualquiera de los siguientes comandos: uname -r, cat /proc/version o hostnamectl | grep Kernel.