[Ubuntu-ni] El desastre de debian afecta a ubuntu?

[JorSol]

Bueno nadie lo pudo haber dicho mejor, y es por este motivo que me
reservaba el comentario... el parche ya esta, pero hay muchas claves
publicas creadas por todo el mundo que puede representar un riesgo.

2008/6/3 Carlos Ortiz Gutierrez <cortizg en ubuntu.org.ni>:
> No tan arreglado, el problema es que aun hay llaves publicas regadas por
> todo el mundo generadas con esa version de OpenSSL, es como intentar sacar
> varias agujas de una montaña de paja.
>
>
> ¿Se soluciona parcheando?
>
> No. No se trata de un fallo de seguridad al uso. Ha existido una fuente de
> claves inseguras que se han esparcido durante dos años. Hay que comprobar y
> regenerar claves. El fallo fue anunciado a la vez que el parche, pero hay
> que tener en cuenta, que las primeras versiones de los parches para Debian y
> Ubuntu contenían regresiones. Han publicado nuevas actualizaciones para los
> propios parches que es necesario aplicar también.
>
> ¿Qué pasa si tengo un servidor web con acceso por HTTPS?
>
> Si las claves han sido generadas con la versión de OpenSSL con el problema,
> las consecuencias son que alguien se puede hacer pasar por el servidor
> porque tendrá la privada de forma instantánea a partir de la pública.
> Además, cualquiera que haya tenido acceso a una conversación cifrada con el
> servidor, podría también descifrarla. Esto es así porque la clave simétrica
> que se utiliza para el cifrado ha sido intercambiada con la ayuda de claves
> asimétricas débiles. Un administrador debe además revocar la clave, generar
> una nueva, enviarla a la Autoridad Certificadora (que cobra por certificar)
> e instalarla. La catástrofe hubiese sito total, si una Autoridad
> Certficadora, hubiese generado claves y firmado certificados con estas
> claves débiles, pues el problema se extendería hacia abajo a todos sus
> clientes, en cuyos certificados ya no se podría confiar. Al parecer han
> comprobado que las principales Autoridades no se ven afectadas.
>
> ¿Qué pasa con SSH?
>
> Los administradores que controlan sus sistemas a través de SSH se suelen
> autenticar a través de su clave privada y el servidor de SSH almacena la
> pública correspondiente. Esto es más seguro que usar una sola contraseña
> simétrica para autenticarse. El servidor cifra una cadena con la clave
> pública del que pretende autenticarse y se la envía, si puede descifrarla le
> deja pasar. En este caso puede que la clave pública sea realmente pública o
> no. En el primer caso, deducir la privada es instantáneo, y en el segundo
> caso, si no se conoce la pública, se debe hacer un ataque de fuerza bruta
> sobre un espacio de claves muy pequeño, algo que tarda unos 20 minutos con
> un ordenador de hoy día. Se ha creado un exploit para esto.
>
> Todos los administradores que permitan a sus usuarios utilizar la clave
> privada para acceder a sus sistemas a través de SSH, deben auditar las
> claves para saber si son de las "débiles". Los administradores de SSH
> también se encuentran ante una tarea concienzuda, peligrosa, (y que deben
> emprender ya) incluso si no utilizan Debian, porque puede que sus claves
> hayan sido generadas en una distribución Debian y exportadas.
>
> Los administradores de SSH comprobarán, con total seguridad, como los
> intentos de acceso ilegítimo se multiplican en estos días.
>
> ¿A Windows le pasó lo mismo?
>
> No. Se demostró que el generador de números aleatorios de Windows era débil,
> pero la diferencia es que según el estudio, había que conocer el estado
> previo del generador para saber el siguiente cálculo. Esto podría permitir
> descifrar conversaciones SSL entre dos sistemas. Pero para poder llegar a
> tener acceso a esa información inicial de la que se deducirían el resto de
> "estados del algoritmo", un atacante necesitaría poder tener acceso como
> administrador en el sistema. Digamos que para poder aprovechar el problema
> del algoritmo y poder descifrar la información, necesitaría tener el total
> control de la máquina para llegar a conocer un estado, con lo que el sistema
> ya estaría comprometido en sí.
>
> Conclusiones
>
> Lo peor no está ocurriendo ahora. Lo verdaderamente grave ha podido ocurrir
> antes (en los últimos dos años si alguien ha conocido este error y lo
> hubiese mantenido en secreto) y después (lo que nos espera a medida que se
> vaya descubriendo que sistemas importantes ha generado claves débiles).
>
> 2008/6/2 JorSol <mailing en jorsol.com>:
>>
>> Con respecto a este incidente me reservo mis comentarios... el
>> problema ya esta arreglado, pero hay que ver desde cuando se viene
>> arrastrando, hay que ser un poco más realistas al respecto.
>>
>>
>> --
>> Jorge Solórzano
>> http://www.jorsol.com
>>
>> --
>> Ubuntu-ni mailing list
>> Ubuntu-ni en lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-ni
>
>
>
> --
> Carlos Ortiz Gutierrez
> www.ubuntu.org.ni
> www.linuxtour.org
> cortizg(at)ubuntu(dot)org(dot)ni
> cortizg(at)gmail(dot)com
> Móbil: +505.8569716
> Ubuntu user #: 14177
> Linux User #: 460808
> --
> Ubuntu-ni mailing list
> Ubuntu-ni en lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-ni
>
>



-- 
Jorge Solórzano
http://www.jorsol.com