No puede uno tener un sábado tranquilo, leñes :)
Acabo de abrir un correo de una de las listas de devel de SSH, en el que Mark Dowd advierte de la existencia de una vulnerabilidad altamente crítica en el famoso y sempiterno OpenSSH (Open Secure SHell).
La gran mayoría ya sabéis qué es OpenSSH, pero por si las moscas, os cuento qué es. OpenSSH es un juego de herramientas que permiten la interconexión punto a punto a través de un túnel cifrado, lo que se denomina habitualmente túnel SSH. A su vez, SSH es un protocolo de comunicación cuya principal fortaleza es, como decía, el cifrado de la comunicación. Además de comunicarse directamente con la shell de la máquina, permite acceder a servidores X, lo que faculta que podamos tener en pantalla aplicaciones gráficas basadas en X, lo que sin duda, es interesante para la administración remota no basada en la consola de comandos.
La vulnerabilidad reside en una defienciente condición de carrera relacionada con la gestión de señales. Esto podría ser aprovechado para que un atacante ejecutara ataques de denegación de servicio e incluso, según el advisory original, ejecutar código arbitrario. Esto, junto al hecho de que sea una vulnerabilidad explotable de modo remoto, confiere al problema estatus de criticidad muy elevada, con lo que es imperativo actualizar, sobre todo teniendo en cuenta que las máquinas con servicios SSH abiertos suelen ser máquinas servidor, domésticas y principalmente, corporativas.
El problema documentado está presente en la versión 4.3 y anteriores. Afortunadamente, los usuarios de OpenSSH tenemos a nuestra disposición ya parche para arreglar el entuerto, con lo que recomiendo actualicéis a la versión 4.4 que subsana el problema con la mayor inmediatez.
La actualización ha sido aprovechada para meter un montón de nuevas funcionalidades en el producto. Me quedo especialmente con dos nuevas features, relacionadas con la redirección de puertos, estrategia típica a la hora de esconder un servicio SSH (puerto 22 en el ordenador pero sin embargo, mapeado por ejemplo al 62312 en el router) con lo que las consultas al 22 contra la máquina acabarán en saco roto, puesto que la redirección haría que el puerto 22 quede aparentemente sin uso.
Estas dos mejoras son nuevos logs que registran números de puerto para aquellos hosts que están almacenados en ~/.ssh/authorized_keys, siempre que se haya solicitado conexión a un puerto no estándar. Por otro lado, se añade una función «ExitOnForwardFailure» cuya misión es provocar la salida con un código de salida que no sea cero, cuando no sea factible acceder a la redirección de puertos solicitadoa.
Veo que Hispasec, con mucho criterio, también pasa a portada este grave problema.
Fedora no ha sacado binarios aún para estas vulnerabilidades.
Cada vez me planteo más cambiar de distribucion.