Los mantenedores del Proyecto FreeBSD han publicado actualizaciones de seguridad para abordar una falla de alta gravedad en OpenSSH que los atacantes podrían explotar para ejecutar código arbitrario de forma remota con privilegios elevados.
La vulnerabilidad, rastreada como CVE-2024-7589tiene una puntuación CVSS de 7,4 sobre un máximo de 10,0, lo que indica una alta gravedad.
«Un controlador de señales en sshd(8) puede llamar a una función de registro que no sea segura para señales asíncronas», según un aviso liberado la semana pasada.
«El controlador de señales se invoca cuando un cliente no se autentica dentro de los segundos de LoginGraceTime (120 de manera predeterminada). Este controlador de señales se ejecuta en el contexto del código privilegiado de sshd(8), que no está aislado y se ejecuta con privilegios de root completos».
OpenSSH es una implementación del conjunto de protocolos de shell seguro (SSH), que proporciona transporte cifrado y autenticado para una variedad de servicios, incluido el acceso remoto a shell.
CVE-2024-7589 ha sido descrito como «otra instancia» de un problema conocido como regreSSHion (CVE-2024-6387), que salió a la luz a principios del mes pasado.
«El código defectuoso en este caso proviene de la integración de blacklistd en OpenSSH en FreeBSD», dijeron los mantenedores del proyecto.
«Como resultado de llamar a funciones que no son seguras para señales asíncronas en el contexto privilegiado sshd(8), existe una condición de carrera que un atacante determinado puede explotar para permitir una ejecución remota de código no autenticado como root».
![Ciberseguridad](https://teknomers.com/es/wp-content/uploads/2024/08/1723190360_817_El-Departamento-de-Justicia-acusa-a-un-hombre-de-Nashville.png)
Se recomienda encarecidamente a los usuarios de FreeBSD que actualicen a una versión compatible y reinicien sshd para mitigar posibles amenazas.
En los casos en los que no se puede actualizar sshd(8), el problema de la condición de carrera se puede resolver configurando LoginGraceTime en 0 en /etc/ssh/sshd_config y reiniciando sshd(8). Si bien este cambio hace que el demonio sea vulnerable a una denegación de servicio, lo protege contra la ejecución remota de código.