Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Se dio a conocer información sobre una vulnerabilidad que fue detectada en la implementación OpenSSH de ssh-agent que permite que el código se ejecute en un sistema que ha proporcionado acceso ssh-agent a un host en el otro extremo de una conexión ssh.

La vulnerabilidad, ya catalogada bajo CVE-2023-38408, es notable debido a que es explotable de manera remota. El ataque solo es posible si el usuario se ha conectado a través de ssh a un sistema controlado por el atacante al habilitar el reenvío de sockets a ssh-agent a través de ssh usando la opción «-A» o la configuración de ForwardAgent en el archivo de configuración.

El proceso de ssh-agent, utilizado para almacenar en caché claves privadas para la autenticación de clave pública, admite un modo de reenvío opcional que permite que el lado remoto de una conexión ssh acceda al ssh-agent en el sistema local para no almacenar datos de autenticación en otros hosts.

La vulnerabilidad está relacionada con la presencia en ssh-agent de soporte para cargar módulos PKCS # 11, que pueden iniciarse, entre otras cosas, a través de un socket unix reenviado a otro sistema a ssh-agent.

Esta característica permite que un atacante que controla el host al que está conectado cargue y descargue inmediatamente cualquier biblioteca compartida de los directorios /usr/lib* en el sistema local de la víctima en un proceso ssh-pkcs11-helper separado. Esta característica aparece en ssh-agent compilado con la opción ENABLE_PKCS11, que está habilitada de forma predeterminada.

Inicialmente, la capacidad de cargar bibliotecas compartidas no se consideró una amenaza para la seguridad, ya que la carga solo es posible desde los directorios del sistema /usr/lib*, que contienen bibliotecas proporcionadas oficialmente por la distribución, y las operaciones con estas bibliotecas se limitan a llamar a las funciones dlopen() y dlclose(), sin llamar a las funciones de la biblioteca.

Sin embargo, se ha pasado por alto que algunas bibliotecas tienen funciones constructoras y destructoras que se llaman automáticamente al realizar las operaciones dlopen() y dlclose(). Esto puede ser suficiente para recoger las bibliotecas necesarias y organizar la ejecución remota de código.

La capacidad de ataque se demuestra en el entorno predeterminado de Ubuntu, ya que no probado en otras distribuciones, que además instala tres paquetes del repositorio «universe» (aun que se supone que en algunas distribuciones es posible atacar en la configuración predeterminada).

Se propusieron 8 variantes del ataque.

Por ejemplo, una de las opciones prometedoras para crear un exploit funcional se basa en el hecho de que la biblioteca libgnatcoll_postgres.so, al ejecutar dlopen(), registra una pila de señales separada utilizada en los controladores de señales llamando a la función sigaltstack(), y después de llamar a dlclose() elimina la asignación de memoria, pero no deshabilita el registro (SS_DISABLE) de la pila de señales.

Para explotar la vulnerabilidad, se realizan las siguientes manipulaciones:

• Se cargan varias bibliotecas para cambiar el diseño mmap.
• Se carga la biblioteca libgnatcoll_postgres.so, se registra una pila de señales alternativa y se ejecuta munmap().
• Las bibliotecas se cargan para cambiar el diseño de mmap y reemplazar la pila de señal separada con otra área de memoria en modo de escritura (por ejemplo, la pila de flujo o los segmentos .data/.bss).
• Carga una biblioteca que registra el controlador de señal SA_ONSTACK pero no lo munmap() cuando se llama a dlclose().
• La biblioteca que recibe la señal y llama al controlador de señales SA_ONSTACK se carga, lo que hace que el área de memoria reemplazada se sobrescriba con marcos de pila del controlador de señales.
• Las bibliotecas se cargan para sobrescribir específicamente el contenido del área de memoria reemplazada.

Sobre la vulnerabilidad, cabe mencionar que esta fue corregida en el lanzamiento de OpenSSH 9.3p2 publicada hace poco. En la nueva versión, las solicitudes para cargar módulos PKCS#11 están deshabilitadas de manera predeterminada. Como solución de seguridad, puede especificar una lista blanca PKCS#11/FIDO vacía (ssh-agent -P ») al iniciar ssh-agent, o definir explícitamente las bibliotecas permitidas en la lista blanca.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.