La vulnerabilidad del kernel Mmap vuelve a estar en la lista

Hemos cubierto nuevas vulnerabilidades del núcleo de Linux en algunos de nuestros artículos anteriores, pero en este artículo vamos a echar un vistazo a una vulnerabilidad que ha sido re-listada accidentalmente. Ambos informes - la re-lista errónea, y la lista original - apuntan a una vulnerabilidad en el mapeo de memoria del kernel de Linux donde se puede desarrollar una condición de carrera cuando se utiliza una función de expansión de memoria.

Hablaremos de la vulnerabilidad en su estado actual. Pero también analizaremos una cuestión clave revelada por la doble inclusión en la lista: si los expertos en seguridad pueden perder de vista tan fácilmente una vulnerabilidad existente hasta el punto de volver a incluirla en la lista como "nueva" y "recién descubierta", ¿qué dice esto sobre el estado de la gestión de vulnerabilidades?

¿Y qué significa esto para los usuarios de Linux de todo el mundo, vulnerables a innumerables estrategias ofensivas, pero dependientes de la ayuda de los expertos en seguridad?

Contenido

1. Comprensión de la vulnerabilidad del kernel mmap

2. Ampliación de memoria

3. Un rápido repaso a las condiciones de la carrera y a la libertad de uso

4. ¿Cuál es el impacto de esta vulnerabilidad en particular?

5. Espera, ya hemos estado aquí antes...

6. Hay una cuestión más amplia en juego

7. La gestión eficaz de la vulnerabilidad es extremadamente difícil

8. Gestión eficaz de las vulnerabilidades

9. Los parches son fundamentales

10. La clave está en la aplicación automatizada de parches

11. Conclusión

Comprensión de la vulnerabilidad del kernel mmap

Las aplicaciones casi siempre necesitan retener algo en la memoria del ordenador mientras se ejecuta la aplicación; de lo contrario, no serían muy útiles. A su vez, el núcleo del sistema operativo necesita asignar espacio de memoria a una aplicación. La función utilizada para solicitar esta asignación de memoria se llama mmap, una función de asignación de memoria.

Por supuesto, en cualquier ordenador hay una cantidad finita de memoria. Al asignar memoria, el núcleo debe gestionar cuidadosamente las demandas y reasignar la memoria no utilizada a otra aplicación si es necesario.

En esta vulnerabilidad específica, existe un caso límite en el que dos aplicaciones diferentes podrían solicitar acceso a la misma memoria. La aplicación que llegue en último lugar fallará en su petición. La razón por la que esto crea una vulnerabilidad es que esta segunda aplicación aún podría leer desde una ubicación de memoria ahora inválida.

Esto, a su vez, desencadenaría un fallo del kernel, lo que podría significar que la información contenida en esa ubicación de memoria fuera revelada. La información podría incluir cualquier cosa, desde algo completamente inocuo hasta una clave de cifrado, y ahí es donde radica el riesgo.

Ampliación de memoria

Vale la pena señalar que la causa de esta vulnerabilidad radica en la forma en que se gestiona la expansión de memoria. El núcleo gestiona la memoria asignada manteniendo una lista de páginas de memoria. En ocasiones, una aplicación puede necesitar más memoria, o incluso renunciar a parte de ella.

Por ejemplo, si el usuario de una aplicación abre un archivo grande, la aplicación puede necesitar ampliar su asignación de memoria. Esta expansión puede ser "hacia arriba" o "hacia abajo" de su memoria asignada existente. Esto normalmente no sería un problema, pero la expansión debe ser manejada con cuidado o puede dar lugar a problemas - las interacciones pueden ocurrir entre múltiples hilos de la misma aplicación o en diferentes aplicaciones.

Desafortunadamente, tal y como descubrieron los investigadores que descubrieron esta vulnerabilidad, en algunos casos las versiones afectadas del kernel de Linux no gestionan correctamente la expansión de memoria. Debido a esta vulnerabilidad, puede surgir una condición de carrera entre ciertas funciones de expansión - expand_downwards y expand_upwards - y las operaciones de liberación de tablas de páginas.

Un rápido repaso a las condiciones de la carrera y a la libertad de uso

Merece la pena repasar rápidamente los dos problemas de seguridad comunes que rodean a esta vulnerabilidad. En primer lugar, muchos problemas de seguridad giran en torno a las condiciones de carrera. Ya hemos explicado cómo funciona la condición de carrera en esta vulnerabilidad: dos aplicaciones solicitan acceso al mismo espacio de memoria. La aplicación que llega "tarde" puede acceder erróneamente a la memoria asignada a otra aplicación.

Este es sólo un ejemplo de una condición de carrera. En general, las condiciones de carrera se producen cuando dos o más hilos -de la misma aplicación o de aplicaciones diferentes- intentan acceder a los mismos datos. Puede tratarse de datos compartidos o de un espacio de memoria asignado. Los atacantes pueden explotar los errores creados por las condiciones de carrera (incluidos los bloqueos del kernel) para una serie de ataques, desde la denegación de servicio hasta el desvío de datos.

Un escenario user-after-free o UAF es aquel en el que una aplicación intenta acceder a un fragmento de memoria después de que haya sido liberado. Por ejemplo, un puntero en una aplicación apunta a un conjunto de datos en memoria dinámica que ya no está en uso -y por tanto libre- cuando en realidad el puntero debería haber sido actualizado.

Una vez más, las vulnerabilidades UAF ofrecen a los atacantes la posibilidad de aprovechar errores de programación para desencadenar una brecha de seguridad, colapsando un sistema o robando datos.

¿Cuál es el impacto de esta vulnerabilidad en particular?

Actualmente, no hay exploits conocidos para esta vulnerabilidad, pero como siempre existe el riesgo de que pueda surgir un exploit. El riesgo de que surja es de medio a bajo, dada la necesidad de acceso a una cuenta local para explotar la vulnerabilidad. No obstante, con acceso a una cuenta local, un atacante puede crear un programa especialmente codificado que desencadene un use-after-free que bloquee el kernel.

Como efecto secundario de ese fallo, el atacante puede diseñar su programa para robar información, por ejemplo, capturando el mensaje de error generado por el fallo, que contiene el contenido de la memoria afectada. Los atacantes también pueden hacer referencia al "volcado del núcleo" que se crea cada vez que el kernel se bloquea. Un ataque bien ejecutado puede filtrar esta información a otra máquina.

Esta vulnerabilidad afecta a las versiones del kernel anteriores a la 5.7.11. La mayoría de las distribuciones han publicado correcciones para la vulnerabilidad - si ha aplicado los parches asociados sus cargas de trabajo estarán protegidas contra esta vulnerabilidad. Y, por supuesto, KernelCare proporciona parches activos para esta vulnerabilidad en todas las distribuciones que soporta.

Espera, ya hemos estado aquí antes...

El CVE para la vulnerabilidad en cuestión, CVE-2020-20200ha aparecido recientemente como reservada (en otras palabras, posiblemente se ha identificado una vulnerabilidad, pero no se ha confirmado). Resulta que se trataba de un informe duplicado. De hecho, la misma vulnerabilidad se notificó en noviembre del año pasado como CVE-2020-29369.

Los investigadores que reservaron CVE-2020-20200 claramente no sabían que la vulnerabilidad ya había sido reportada. Como resultado, CVE-2020-20200 simplemente se incluyó en CVE-2020-29369. No es la primera vez que una vulnerabilidad de seguridad se notifica por duplicado, y este último ejemplo vuelve a poner de actualidad la cuestión de la doble notificación y lo que implica.

Incluso personas estrechamente relacionadas con la seguridad del núcleo de Linux aceptaron la segunda revelación. Sí, es positivo que diferentes individuos y equipos estén comprobando estas vulnerabilidades, pero es preocupante que las vulnerabilidades existentes puedan olvidarse tan fácilmente en el proceso.

Hay una cuestión más amplia en juego

Se puede argumentar que la doble notificación sugiere una falta de conocimiento de las vulnerabilidades en la comunidad de seguridad en general. Esta vulnerabilidad en concreto afecta a características fundamentales del kernel, pero el hecho de que se haya notificado dos veces sugiere que su existencia no es tan conocida como debería.

Es fácil culpar de la falta de concienciación a los expertos en seguridad, pero lo cierto es que estas personas y equipos simplemente se pierden en una avalancha de vulnerabilidades. La creciente ola de problemas de seguridad simplemente se lleva cualquier oportunidad real para un solo individuo o incluso un equipo para estar constantemente al tanto de las vulnerabilidades críticas y reportadas.

En otras palabras, estamos diciendo que ni siquiera los expertos pueden hacer frente sistemáticamente a la avalancha de vulnerabilidades que se están descubriendo.

La gestión eficaz de la vulnerabilidad es extremadamente difícil

Si los expertos en seguridad tienen dificultades con la gestión de vulnerabilidades, huelga decir que el personal encargado de las operaciones informáticas cotidianas tendrá muchas más. Un administrador de sistemas típico ya está abrumado con las tareas cotidianas: tendrá suerte si recuerda las últimas cinco o diez vulnerabilidades que recientemente requirieron parches. ¿Pero docenas o cientos? Es poco probable.

La implicación en la vida real es que las vulnerabilidades se gestionarán mal. Muchas de ellas pasarán desapercibidas. Otras se parchearán, pero con toda probabilidad mucho después de que se haya publicado el parche.

Este tratamiento "imperfecto" de las vulnerabilidades es lo que deja una oportunidad a los actores malintencionados. Peor aún, los atacantes suelen utilizar herramientas automatizadas para buscar vulnerabilidades no parcheadas. En otras palabras, la aplicación de parches poco sistemática no es muy diferente de la ausencia de parches.

Gestión eficaz de las vulnerabilidades

La gestión de la vulnerabilidad se beneficia de una serie de herramientas. Una gestión rigurosa de las credenciales y los permisos sería una herramienta clave, por ejemplo, para limitar el daño que un atacante puede hacer con credenciales robadas.

Del mismo modo, la supervisión de la seguridad puede ayudar a detectar un ataque en curso y darle la oportunidad de limitar los daños. Y, por supuesto, los cortafuegos y otras herramientas de seguridad pueden detener los ataques automáticos antes de que arraiguen.

Los parches son fundamentales

Sin embargo, la aplicación rápida y coherente de parches es, con mucho, la forma más eficaz de gestionar las vulnerabilidades. En muchos casos se publica un parche para una vulnerabilidad mucho antes de que aparezca un exploit. Incluso en los casos en los que los exploits salen a la luz antes de que esté disponible un parche, el intervalo entre el exploit y el parche es relativamente estrecho.

En cambio, con un parcheado ineficaz, el tiempo que transcurre entre la aparición de un exploit y la aplicación del parche puede ser de años, o incluso indefinido.

Sabemos que parchear es difícil. Por ejemplo, la aplicación de parches es perjudicial, ya que a menudo es necesario reiniciar el servidor para completarla. Parchear durante las ventanas de mantenimiento ayuda, pero los parches críticos deben aplicarse incluso fuera de una ventana de mantenimiento.

La clave está en la aplicación automatizada de parches

La aplicación de parches requiere mucho tiempo si se hace manualmente. La aplicación automatizada de parches es una forma mejor de avanzar, ya que garantiza que los parches se respondan de forma coherente y sin la habitual merma de recursos informáticos.

La forma más eficaz de gestionar los parches es, por supuesto, la aplicación automatizada de parches combinada con parches sin reinicio. En otras palabras, parches que se aplican en directo sin necesidad de reinicios. La aplicación de parches en vivo y sin reinicios implica que los servidores se mantienen actualizados, sin interrumpir los servicios subyacentes.

Ese servicio es en lo que consiste KernelCare live patching se trata de parchear sus servidores de forma automática y sin interrupciones, sin necesidad de reiniciar.

Conclusión

La avalancha de vulnerabilidades es extremadamente difícil de seguir. Incluso los expertos más involucrados en la gestión de vulnerabilidades se equivocan a veces. No cabe duda de que los administradores de sistemas y los expertos en seguridad empresarial cometerán errores similares, a menos que utilicen herramientas automatizadas de última generación.

La aplicación de parches automatizada, en tiempo real y sin reiniciar de KernelCare aplica parches para la vulnerabilidad mmap mencionada y muchos otros tipos de vulnerabilidades en cuanto se publica el parche. Herramientas como KernelCare son, por tanto, fundamentales en la lucha contra las vulnerabilidades y los exploits asociados.