Login Barrapunto
Descubierta vulnerabilidad en OpenSSH
IFM nos cuenta: «Un grupo de investigadores del Information Security Group (ISG) de la Universidad Royal Holloway de Londres acaba de hacer público un fallo en el ampliamente utilizado protocolo de comunicación SSH. El fallo se ha encontrado en la versión 4.7 de OpenSSH y recomiendan que todos los usuarios actualicen a la versión 5.2 ya que ofrece varias contra-medidas que pueden evitar un ataque. Pueden ser vulnerables también otras implementaciones de SSH, según el grupo de seguridad londinense.
Enviando paquetes especialmente manipulados, un atacante tiene una probabilidad entre 262.144 de recuperar 32 bits de texto plano de un texto previamente cifrado, de forma arbitraria.
"Es un fallo de diseño de OpenSSH. Las otras vulnerabilidades han sido más por errores de codificación." Declaró Patterson, profesor del ISG.
Queda claro que las probabilidades son muy limitadas. Pero el fallo de diseño sigue planteando una amenaza significativa, dada la forma en que muchas aplicaciones emplean SSH.
»En los avisos de seguridad del CPNI y de OpenSSH recomiendan configurar OpenSSH usando AES en modo CTR, que no es vulnerable a este ataque. Ésta será la configuración por defecto en las siguientes versiones.
« Google, obligado a eliminar datos de carácter personal | Tres millones de firmas piden una alternativa 'más justa' al canon digital »
Historias relacionadas
[+]
Mac OS X no corrige una grave vulnerabilidad en Java Runtime Environment
Cuentan en Una al día, de Hispasec: «A pesar de que en la última macro-actualización de Mac OS X se han corregido 67 vulnerabilidades, al parecer han dejado sin solución un grave problema en el JRE (Java Runtime Environment) que puede ser aprovechado por atacantes para ejecutar código con solo visitar una página web. JRE viene activado por defecto en el sistema operativo de Apple. El navegador Safari, por tanto, lo llamará para interpretar páginas que contengan applets. Si se manipula especialmente uno de ellos (el error tiene su origen en la clase java.util.Calendar), se podría ejecutar código en el sistema vulnerable. Los detalles son públicos, existe prueba de concepto y por ello se recomienda deshabilitar el JRE en Mac OS X.» También lo comentan en Slashdot y reddit.
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
Para algunos
(Puntos:2)( http://barrapunto.com/ )
Algunos creyeron que con 0's y 1's no se podría hacer nunca nada.
La informacion es oro. Y en informática es platino.
¿¿PETER?? ¿Demostenes? Y actualmente Lockpeter
Muchas grácias por la info mig21
(Puntos:3, Informativo)( http://egfh.gnusystems.net/ | Última bitácora: Jueves, 19 Febrero de 2009, 08:13h )
Ciphers aes256-ctr
Al archivo
Podéis añadir otras cifras separadas por coma, aunque la que se usará por defecto es la primera a no ser que se especifique desde el cliente.
La lista completa de cifras está en el man page de sshd_config (man sshd_config)
"La vida es injusta, por suerte para nosotros." -- Oscar Wilde
Leyendo...
(Puntos:2)"In this case, it might be possible to recover on average 44 bits of plaintext per hour (assuming a very fast 10 connections per second)"
En cualquier caso, y en el mismo Advisory ya mencionan que estableciendo un límite de reintentos de conexión, se mitiga éste vector (que probablemente sería el principal).
Imagino que implementando denyhosts o fail2ban para monitorizar a ssh, puede reforzarse todavía más la resistencia a éste ataque, sin tener que andar cambiando modos de cifrado.
¿Sugerencias?
Si mal no recuerdo...
(Puntos:1)Probabilidad
(Puntos:1)Bueno depende delo que tarde cada ataque podriamos hablar de tiempos finitos o no.
Te pueden declarar estar muerto pero estar pensando