Encontrada otra vulnerabilidad Futex en el Kernel (CVE-2021-3347)

Las vulnerabilidades de Linux se acumulan. Año tras año. Podría decirse que es inevitable, dado el complejo entorno informático actual. No obstante, resulta frustrante que los mismos elementos críticos del núcleo del sistema operativo Linux sigan apareciendo como áreas vulnerables.

Hasta 2020 inclusive, hay catorce CVEs listadas que cubren la implementación futex de Linux. Es cierto que los futex son formidablemente complejos. Aunque proporcionan una funcionalidad esencial, a menudo no se entienden con claridad, y algunos podrían argumentar que las vulnerabilidades son inevitables dada la complejidad de la implementación de futex.

Desafortunadamente, a finales de enero de 2021, surgió otra vulnerabilidad del kernel de Linux que implica un mal manejo de futex. Peor aún, implica una peligrosa vulnerabilidad de uso después de libre.

En este artículo, explicamos por qué el núcleo de Linux tiene una llamada al sistema futex y explicamos por qué las complejidades de las implementaciones de futex pueden dar lugar a vulnerabilidades. También leerás más sobre las vulnerabilidades use-after-free y por qué son tan peligrosas.

Cubriremos lo que sabemos sobre las características únicas de la nueva vulnerabilidad - y lo que su organización puede hacer para protegerse contra ella, y contra las vulnerabilidades del núcleo Linux en general.

Contenido

1. Introducción a los futex

2. ¿Qué es un futex?

3. El PI-Futex

4. Una larga historia de hazañas futex

5. Comprender las vulnerabilidades de uso después de la liberación

6. Lo que sabemos sobre la nueva vulnerabilidad de futex

7. El impacto potencial de la última vulnerabilidad futex

8. Protección contra los exploits futex y otras vulnerabilidades del kernel

9. Conclusión

Introducción a los futex

Para entender por qué la última vulnerabilidad de Linux es tan crítica, primero debemos comprender cómo funcionan los futex.

El uso de un futex, y la vulnerabilidad creada por el uso indebido de futex, implican capacidades de bajo nivel del SO que se utilizan para ayudar a coordinar procesos en una aplicación, particularmente cuando una aplicación necesita coordinar tareas interdependientes que llevan diferentes prioridades.

¿Qué es un futex?

Las tareas simultáneas suelen requerir el control de los mismos recursos, como las variables, pero lo hacen en momentos distintos y a ritmos diferentes. El sistema operativo necesita coordinar este control sobre los recursos. Antes de que se introdujeran los futex en el núcleo de Linux en 2003, era necesario realizar llamadas al sistema para bloquear y desbloquear recursos compartidos.

Sin embargo, las llamadas al sistema consumen mucho procesador. Un futex (abreviatura de "fast userspace mutex") ofrece una alternativa a bloquear y desbloquear constantemente un recurso mediante llamadas al sistema. En su lugar, un futex proporciona una forma eficiente de recursos para que los procesos compartan un bloqueo sobre una variable. Los futex son complejos, y una explicación exacta va más allá del alcance de este artículo. Puedes leer un poco más en el artículo de Wikipedia aquí.

El PI-futex

Los Futex han evolucionado con el tiempo para adaptarse a un entorno informático cambiante. Una de estas evoluciones es la introducción de lo que se denomina herencia prioritaria o PI-futex.

¿Por qué necesitamos un PI-futex? Bajo la arquitectura futex estándar, el sistema operativo puede tener dificultades para garantizar que una tarea de alta prioridad disfrute de una ejecución determinista cuando esa tarea de alta prioridad comparte un bloqueo con una tarea de baja prioridad.

Como ejemplo de la vida real, consideremos un reproductor multimedia. En primer lugar, el reproductor multimedia debe garantizar que los medios de audio o vídeo pasen por el ordenador en tiempo real, sin contratiempos ni interrupciones. Es una tarea de alta prioridad. Los usuarios se frustrarán rápidamente si los medios no se reproducen con fluidez.

Al mismo tiempo, el reproductor multimedia debe gestionar otras tareas de prioridad media y baja: piense, por ejemplo, en los controles del reproductor, las carátulas de los álbumes y las recomendaciones. Hacer malabarismos con estas operaciones de forma que no afecten a la experiencia del usuario puede ser todo un reto para los programadores, ya que hay elementos comunes implicados, todos ellos progresando a distintas velocidades.

Existen innumerables situaciones en las que una aplicación debe gestionar una variedad de tareas con diferentes prioridades, pero que a menudo implican los mismos datos. Un ejemplo sería un servidor web que atiende consultas simultáneas de usuarios de todo el mundo.

Un PI-futex es, por tanto, un futex especialmente diseñado que permite al sistema operativo implementar bloqueos compartidos, garantizando al mismo tiempo que las instrucciones con diferentes prioridades se ejecuten a tiempo.

Una larga historia de hazañas futex

La complejidad de PI-futexes debería darte una idea de por qué manejar futexes puede conducir con relativa facilidad a problemas de seguridad. En general, los sistemas de núcleo múltiple agravan los problemas con los futexes, ya que los programadores pueden tener dificultades para manejar la complejidad de los futexes y, por lo tanto, aplicar una programación concurrente mal implementada que abre la puerta a los exploits.

No es de extrañar, pues, que ya se conozcan 14 vulnerabilidades futex en el kernel de Linux. La primera de ellas CVE-2005-0937fue notificada en 2005. Una de estas vulnerabilidades recibió mucha cobertura, ya que dio lugar a la posibilidad de un ataque de escalada de privilegios en Android que permitía a los usuarios rootear teléfonos Android simplemente utilizando un navegador web.

Llamado el exploit Towelroot, la vulnerabilidad fue asignada CVE-2014-3153. El exploit gira en torno a un error en la implementación de futex, y en la funcionalidad de cola futex para ser específicos. Al igual que la última vulnerabilidad, Towelroot también afecta a PI-futexes.

Sobrecargando la cola futex un hacker puede sobrecargar Android, dejándolo en un estado en el que piensa que la aplicación activa debería ser root. Esto, a su vez, abre la puerta a otros exploits. La vulnerabilidad no sólo afecta a Android, sino también a muchos sistemas operativos basados en Linux.

Comprender las vulnerabilidades de uso después de la liberación

El núcleo del último exploit Linux futex es algo llamado vulnerabilidad use-after-free o UAF. Antes de examinar el exploit en sí, echemos un vistazo a lo que implica una vulnerabilidad UAF.

El escenario user-after-free ocurre cuando una aplicación intenta acceder a un trozo de memoria aunque ese trozo de memoria ya haya sido liberado.

Los escenarios UAF varían, pero un ejemplo puede ser cuando un puntero en un programa apunta a un conjunto de datos en memoria dinámica que ya ha sido borrado. Normalmente, el puntero debería borrarse para reflejar los datos borrados. Sin embargo, a veces, debido a errores de programación, el puntero sigue existiendo y hace referencia a memoria de programación vacía. Es lo que se llama un puntero colgante.

Un puntero colgado puede provocar la corrupción de datos y el bloqueo del programa. Los punteros colgantes y los UAF en el ancho pueden ser explotados por hackers para ejecutar código arbitrario y malicioso.

Las vulnerabilidades Use-after-free son relativamente comunes y existen en todo el espacio de desarrollo. Los exploits UAF son comunes en parte porque es bastante difícil identificar un UAF manualmente: Los UAF tienden a existir debido a acciones que se combinan en diferentes partes de una aplicación, por lo que detectar un UAF requiere inspeccionar toda la base de código en su conjunto en lugar de sólo segmentos individuales de código.

Es crítico, por tanto, que la última vulnerabilidad futex de Linux cree el espacio para exploits UAF que pueden ser extremadamente difíciles de detectar.

Lo que sabemos sobre la nueva vulnerabilidad de futex

Como dijimos antes, la última vulnerabilidad también afecta a PI-futexes. Los detalles completos aún están emergiendo, pero esencialmente esta vulnerabilidad futex en particular crea el riesgo de un exploit usuario-después-libre.

Lo que sabemos hasta ahora es que, en esencia, cuando una aplicación maneja mal un PI-futex el kernel de Linux puede devolver un estado inconsistente. En algunos casos, este estado inconsistente puede resultar en una oportunidad de uso-después-libre en la pila del kernel de tareas de Linux.

Aún no se han publicado todos los detalles de la última vulnerabilidad, pero esperamos que salgan pronto a la luz. Las investigaciones realizadas por nuestro equipo sugieren que el problema afecta a todas las distribuciones de Linux que utilizan un kernel a partir de 2008 - esencialmente cubriendo todas las implementaciones de Linux en la naturaleza.

El impacto potencial de la última vulnerabilidad futex

Preocupa especialmente el hecho de que esta vulnerabilidad futex en particular abra la puerta al abuso de "usar después de libre". Y, evidentemente, el número de sistemas Linux afectados es muy desconcertante.

Por supuesto, el problema con las vulnerabilidades futex y UAF en general es que pueden dar lugar a una gran variedad de exploits si un programador se pone creativo. Actualmente, no existe ningún exploit para la última vulnerabilidad, pero el riesgo de que surja un código exploit es alto.

Esperamos que los riesgos de esta vulnerabilidad giren en torno a los riesgos típicos de los exploits UAF. Piense en ataques DoS, por ejemplo. Existe el riesgo de que la nueva vulnerabilidad futex pueda utilizarse para bloquear sistemas con el objetivo de interrumpir las operaciones, o denegar el servicio a sus clientes. Esto se debe a que las vulnerabilidades UAF pueden utilizarse a menudo para bloquear aplicaciones en ejecución.

Los UAF también suelen permitir a los hackers ejecutar código malicioso, lo que a su vez puede dar lugar a toda una serie de problemas habituales de ciberdelincuencia, como el robo de datos. Los lectores comprenderán las posibles consecuencias: pérdidas económicas, daños a la reputación, etc.

Protección contra los exploits futex y otras vulnerabilidades del kernel

Cuando se trata de vulnerabilidades del núcleo de Linux, la respuesta es, y siempre ha sido, la aplicación de parches. Las vulnerabilidades de Futex han dado lugar sistemáticamente a cambios en el núcleo, y a los correspondientes parches. Lo que es menos consistente, sin embargo, es la aplicación de estos parches.

Si su organización aplica parches de forma sistemática, probablemente disfrutará de protección contra la última vulnerabilidad futex antes de que los exploits empiecen a surgir en la naturaleza. Sin embargo, aplicar parches sistemáticamente no es tan fácil como parece.

La aplicación de parches lleva mucho tiempo y a menudo requiere reinicios que implican tiempo de inactividad, y clientes descontentos o pérdida de ingresos. Por esta razón, muchas empresas descuidan la aplicación de parches, lo que puede significar que las vulnerabilidades conocidas sigan siendo explotables.

Una alternativa son los parches automatizados y sin reinicios. KernelCare, por ejemplo, puede mantener sus distribuciones Linux parcheadas sin esfuerzo, cubriéndole automáticamente frente a vulnerabilidades conocidas, incluidos los últimos exploits relacionados con futex.

Conclusión

Actualmente, no hay ningún exploit in the wild que conozcamos que ponga en peligro sus sistemas basándose en esta vulnerabilidad del kernel Linux recientemente descubierta. Sin embargo, existe un alto riesgo de que surjan exploits, simplemente está en la naturaleza de las vulnerabilidades UAF.

Como administrador de sistemas o experto en seguridad preocupado, debería tratar esta nueva vulnerabilidad como lo haría con cualquier otra. Parchéela cuando se publique el parche.

¿No dispone de recursos para aplicar parches? ¿Está harto de los tiempos de inactividad relacionados con los parches? Pruebe KernelCare.