Una vulnerabilidad significativa en el parche de intercambio de claves GSSAPI fue aplicada por numerosas distribuciones de Linux en sus paquetes de OpenSSH. La falla, identificada como CVE-2026-3497, fue descubierta por el investigador de seguridad Jeremy Brown. Permite a un atacante provocar la caída de procesos secundarios de SSH de manera confiable y potencialmente violar los límites de separación de privilegios, todo con un único paquete de red manipulado.

Una vulnerabilidad significativa en el parche de intercambio de claves GSSAPI fue aplicada por numerosas distribuciones Linux en sus paquetes OpenSSH.

El fallo, registrado como CVE-2026-3497, fue descubierto por el investigador de seguridad Jeremy Brown. Permite a un atacante bloquear procesos hijos de SSH de manera fiable y potencialmente violar los límites de separación de privilegios, todo con un solo paquete de red manipulado.

La vulnerabilidad surge de un defecto de una línea de código dentro de kexgsss.c, el manejador de intercambio de claves GSSAPI del lado del servidor. Se utilizó una función no terminante, sshpkt_disconnect(), en el caso de manejo de errores predeterminado donde en realidad se pretendía usar la función que termina el proceso, ssh_packet_disconnect().

Debido a que sshpkt_disconnect() solo pone en cola un mensaje de desconexión y retorna en lugar de detener la ejecución, el manejador de errores continúa hacia código que lee una variable de pila no inicializada llamada recv_tok.

Vulnerabilidad GSSAPI de OpenSSH

El contenido de esa variable se envía luego al proceso monitor privilegiado a través de IPC y se pasa a gss_release_buffer(), que puede llamar a free() en un puntero basura, resultando en una corrupción confirmada del heap.

El análisis de Brown clasifica el error bajo CWE-824 (acceso a un puntero no inicializado) y CWE-908 (uso de un recurso no inicializado). Los detalles clave del impacto incluyen:

• Un solo paquete SSH manipulado de aproximadamente 300 bytes es suficiente para activar el fallo — no se requieren credenciales
• En sistemas x86_64, la explotación produce SIGABRT (señal 6) o SIGSEGV (señal 11) con un bloqueo de SSH de 90 segundos
• Los bloqueos de procesos hijos son 100% fiables en las configuraciones probadas
• Hasta 127KB de datos del heap pueden transmitirse al proceso monitor a nivel de root a través del canal IPC de privsep, lo que representa una grave violación de los límites de separación de privilegios

La gravedad de la vulnerabilidad varía considerablemente entre distribuciones debido a diferentes opciones de compilador y banderas de optimización. Clang compilado con -O0 deja un valor de puntero de 0xfffbe600 con una longitud de 4 bytes, mientras que GCC compilado con -O2 -fno-stack-protector deja una dirección válida del heap con una longitud de 127,344 bytes.

Una matriz de prueba de ocho compilaciones confirmó que recv_tok.value puede variar desde NULL hasta direcciones de pila, direcciones del heap o regiones de memoria completamente no mapeadas.

Los sistemas que ejecutan servidores OpenSSH de Ubuntu y Debian con GSSAPIKeyExchange yes habilitado están confirmados como potencialmente afectados. Dado que varias versiones diferentes del parche KEX GSSAPI están en circulación en el ecosistema Linux, el alcance del impacto probablemente se extienda más allá de estas dos distribuciones.

La solución es sencilla: reemplazar las tres instancias de sshpkt_disconnect() con ssh_packet_disconnect() en los sitios de llamada del lado del servidor dentro de kexgsss.c. Ubuntu ya ha preparado un parche que aborda este problema.

Los administradores que ejecutan OpenSSH con intercambio de claves GSSAPI habilitado deben aplicar las actualizaciones disponibles de su distribución de inmediato o deshabilitar GSSAPIKeyExchange como mitigación temporal.