Se han descubierto dos vulnerabilidades críticas en sslh, un demultiplexor de protocolo ampliamente utilizado que permite que varios servicios compartan un único puerto de red. Estas fallas, identificadas como CVE-2025-46807 y CVE-2025-46806, podrían ser explotadas de forma remota para desencadenar ataques de denegación de servicio (DoS).
Las versiones de sslh anteriores a la v2.2.4 se ven afectadas por estas vulnerabilidades. Se recomienda a los usuarios actualizar a la última versión, donde las correcciones ya están disponibles, para mitigar estos riesgos de seguridad.
La primera vulnerabilidad implica el agotamiento del descriptor de archivos que conduce a una falla de segmentación en las implementaciones sslh-select y sslh-ev.
Según el equipo de seguridad de SUSE, el manejo de la conexión UDP del sslh contiene una falla crítica donde los tiempos de espera de conexión solo se verifican durante la actividad de la red, lo que permite a los atacantes agotar el límite de descriptores de archivos 1024.
«Cuando se encuentra el límite del descriptor de archivo, sslh falla con una falla de segmentación, ya que intenta eliminar la referencia a new_cnx, que es un puntero NULL en este caso», explica el informe.
Esto crea un sencillo vector DoS remoto que interrumpe por completo la disponibilidad del servicio.
La vulnerabilidad puede desencadenarse creando numerosas conexiones UDP donde cada una envía solo un byte de datos. Los investigadores reprodujeron con éxito este problema probando la sonda OpenVPN configurada para UDP, enviando solo un byte 0x08 por conexión.
La solución, implementada en la confirmación ff8206f7c, soluciona el error de segmentación, pero los investigadores señalan que «los sockets UDP potencialmente aún permanecen abiertos durante más tiempo hasta que sslh procese más tráfico».
La segunda vulnerabilidad surge de accesos a memoria desalineados en la sonda del protocolo OpenVPN. El problema ocurre en la ruta del código UDP de la función is_openvpn_protocol(), donde ciertas operaciones intentan acceder a la memoria no alineada:
Este código intenta eliminar la referencia a un puntero uint32_t que apunta a la memoria ubicada 25 bytes después del inicio del búfer de red asignado al montón.
En arquitecturas como ARM, esto provoca un error SIGBUS, lo que provoca un bloqueo y una interrupción del servicio.
Los investigadores reprodujeron esto enviando una secuencia de al menos 29 0x08 bytes, lo que provocó errores de alineación en tiempo de ejecución.
La solución en la confirmación 204305a88fb3 implementa un enfoque más seguro usando memcpy() para copiar datos enteros en una variable de pila local en lugar de desreferenciar directamente los punteros en datos de red sin procesar.
Estas vulnerabilidades afectan principalmente a los sistemas que utilizan sslh para multiplexar servicios en puertos compartidos, una configuración común para eludir las restricciones del firewall corporativo.
La implementación sslh-fork maneja el agotamiento de los descriptores de archivos mejor que otras variantes, pero aún podría ser vulnerable a ataques excesivos de creación de procesos.
Se recomienda a los administradores que actualicen inmediatamente a sslh v2.2.4, que contiene correcciones para ambas vulnerabilidades.
Para mayor protección contra ataques DoS más sofisticados, el equipo de seguridad de SUSE recomienda «personalizar su configuración para imponer límites de consumo de recursos a nivel del sistema operativo».
«En general, creemos que sslh está en buena forma. Hay poca superficie de ataque y se han implementado protecciones de forma predeterminada. Con los dos vectores DoS remotos solucionados, debería ser seguro usar sslh en producción», concluye el informe de seguridad.
