LANUX

Probablemente si sos admin a esta altura ya te habrás enterado de la vulnerabilidad de OpenSSL en Debian, descubierta por un chamigo argento, LucianoBello que muchos de la comunidad conocemos
Si accedes directamente sin login de GDM/KDM y tu password de root es ‘123′, probablemente leer esto sea una perdida de tiempo para vos
El problema es el siguiente: en un patch de Debian al paquete OpenSSL que fue aplicado por mediados de 2006, se introdujo una seria vulnerabilidad en el manejador pseudo-aleatorio de números (PRNG).
Para los que no saben que es eso o que es OpenSSL, un resumen pequeño y
una lectura obligada en Wikipedia.
OpenSSL es una implementación libre de los protocolos SSL y TLS que se usan como herramientas de criptografía, o sea, para ocultar cosas básicamente.

Entonces, lo que hace el PRNG es eso, generar números que intentan tener la mayor entropía (”aleatoriedad”) posible usando distintos parámetros.

Esto hace que, por ejemplo, una conexión segura via SSH sea justamente “segura” por que las claves que se utilizan para establecer el canal de comunicación son *extremadamente* largas y “aleatorias”.

Lamentablemente la parte afectada fue una de las encargadas de generar la mayor parte de la entropía de los números generados por OpenSSL, reduciendo drásticamente los tiempos de ataque por fuerza bruta a cuestión de horas o minutos.

Antes de entrar en shock, lo importante es actuar con prudencia.
El fallo fue introducido en Sept de 2006, así que la sugerencia es que ante la duda, vuelvas a generar todas las llaves que hayan sido creadas vía OpenSSL en un sistema Debian (o derivados de Debian) desde 2006 hasta ahora, actualización de libssl mediante claro.
Esto afecta a llaves SSH (llaves RSA y DSA), certificados SSL (x509), y todo lo que haya sido compilado contra libssl.

Lo que la mayor parte de todos tendremos que hacer mínimamente es regenerar las llaves RSA/DSA para el servidor SSH:

# rm /etc/ssh/ssh_host_*
# dpkg-reconfigure openssh-server


Aquí les dejo una documentación muy completa con casi todos los productos afectados y como solucionarlos.

Si bien el alcance de esto es casi catastrófico a nivel industrial, yo personalmente estoy bastante satisfecho de la velocidad de respuesta ante catástrofes, como dijo Luciano en un post por ahí, el sistema funciona.

Algunos creerán que estoy completamente loco, ¿Como es eso de que funciona, si es un problema terrible?
Bueno, este tipo de cosas no solo ocurren en los modelos de desarrollo libres, los miles de ejemplos de otras plataformas que fueron expuestas fallas de seguridad (incluso en modelos cerrados) muestran respuestas de semanas a meses!

A los que tuvieron que hacer los cambios de Huso Horario el verano pasado, en Debian (por citar el que conozco) los paquetes estuvieron disponibles (DD argentina mediante) a 2 horas luego del anuncio oficial del gobierno, mientras los administradores de windozes sabrán bien M$ recién puso a disposición el parche la 2da quincena de Febrero, casi 2 meses después del anuncio, y solo para XP SP2 y Windoze2003
A mi entender es una falla masiva entre el control del mantenedor del paquete, los desarrolladores de OpenSSL (por obviar información mínima en la parte mas crucial de todo OpenSSL), la comunidad de desarrolladores, y todos los que absorben código sin siguiera mirarlo también.
Claramente creo que no es una falla del modelo de desarrollo libre, como muchos por ahí dicen, “hubiese sido mejor si el código no fuese publico”, nada mas errado a mi entender…

Como todo esto surgió tan rápido, la mayor parte de la doc esta en ingles (google translate!), pero es la mas completa.

Les dejo mis links preferidos.