http://lists.debian.org/debian-sec [...] 00152.html

Sarge n'est pas affectée, tout ce qui est plus récent (etch, testing et unstable) l'est.
 
Allez voir l'alerte pour des outils permettant de tester la compromission de vos clés et les méthodes de rattrapages (globalement, dégager toutes vos clés et les recréer).
 
Alterte Ubuntu confirmant qu'elle est également compromise à partir de Feisty (7.04) et jusqu'aux versions récentes d'Intrepid Ibex: http://www.ubuntu.com/usn/usn-612-1

Dans le genre grosse faille, ca se pose (remarque l'exploit du kernel pour usurper les droits root c'était pas mal aussi)

De ce que je comprends, openssl utilise l'état non initialisé de la mémoire (à l'allocation donc) comme source de random.
Mais faire ça lève des warnings dans valgrind (détecteur de fuite mémoire), et donc pour corriger le problème le paquet a été patché, la mémoire initialisée à zéro avant usage. Et du coup une des sources de random n'est pas random du tout
http://www.links.org/?p=327
 
Un nettoyage de code assez malheureux, mais si on vérifie ici : http://marc.info/?t=114651088900003&r=1&w=2
on voit qu'en gros côté Debian on a vu que cela ferait moins d'entropie et côté openssl on a dit que malgré tout ce n'était pas forcément à jeter si cela aidait au debug.

edit :
plus d'infos http://www.aigarius.com/blog/2008/ [...] different/
plus d'infos http://reddit.com/info/6j7a9/comments/c03zxko

La grande question : le générateur est plus prédictible, mais dans quelle mesure cela rend-il une attaque possible ?
Si c'est juste lié à la clef générée lors de la négociation Diffie-Hellman, elle change à chaque connexion ssh alors...
Ce qui est sûr c'est que le "détecteur" de clefs faibles cité dans la Debian Security Alert détecte très très rapidement si la clef est faible ou pas.

Il faut :
- upgrader openssl
- régénerer ses clefs ssh clients si on fait du ssh, et les déployer partout où elles servent.
- régénerer ses certificats X509 si on fait du https
- régénerer les clefs du server openssh et le redémarrer.

Bref tout ce qui est en relation avec openssl

Pour bien faire les choses il faudrait aussi changer les password qui ont été tapés à un moment dans une session ssh trop faible.

Inconvénient Debian/Ubuntu/dérivés : il y a un manque de contrôle qualité dans les patch appliqués. Si une distribution fait un patch, il faut soit le faire remonter au développeur qui maîtrise le sujet, soit avoir une procédure très stricte de validation. On a besoin d'un système simple pour passer en revue ce genre de trucs, surtout sur les paquets critiques, et surtout si on est une distribution qui patche tout tout le temps (ce qui est le cas de Debian).

Inconvénient du système à plus grande échelle : si les développeurs upstream se plantent (si le nouveau codeur récemment arrivé fait de la merde), on ne le verra pas sans contrôle qualité (revue du code ?)

Avantage du système : la faille est publiée, la correction aussi. C'est toujours mieux que de résoudre le problème discrètement et sans communiquer dessus.

Accessoirement, il est également conseillé de passer l'outil fourni dans le lien initial sur les clés même si ce n'est pas un système basé sur debian: toute clé créée sous debian ou ubuntu et importée est également compromise

Adieu, monde cruel

C'est clairement une sacrée merde cette compromission avec OpenSSL.    
 
Faudra vraiment que les dev communiquent mieux et davantage avec l'upstream à l'avenir, surtout pour les paquets de ce type... le cas présent est une leçon magistrale en la matière. En attendant ça va être un beau bordel dans les jours à venir (niveau re-génération de clés et certifs on va pas être déçus...) ; une histoire qui risque de faire grand bruit dans le milieu...  

pour rebondir : http://blog.drinsama.de/erich/en/l [...] l-desaster

La mémoire non initialisée n'est pas forcemment "totallement" initialisée de ce que je comprends... Si le compilo a des options spécifiques alors on peut avoir le même comportement..

Grand bruit je sais pas... parce que c'est surtout une faille "théorique"... qu'il sera difficile (impossible ?) d'exploiter... et regénérer des centaines de clés je suis carrément pas chaud...

edit : il n'y a que les gens qui ne font rien qui ne se trompent pas... pour le coup je rejoins lucas nussbaum. Les devs d'openssl ont aussi le droit de commenter leur code, surtout aux endroits "litigieux" au niveau sens.

Ca serait intéressant d'avoir plus d'infos sur la diminution de l'entropie du RNG dû à la faille,  si on perd quelques bits sur 256b c'est pas trés grave, si on passe de 256 à 32 là c'est plus gênant.

en faisant qq recherches il apparait que les clés peuvent apparemment subir assez rapidement une analyse

Ouais enfin d'un autre côté quand on connaît rien en crypto on va pas modifier du code de crypto juste pour faire taire un warning dans valgrind

edit: et si on le fait quand même, on upstream le patch afin que les gens qui s'y connaissent puissent le voir et l'analyser avant de l'appliquer sans en parler aux responsables

on est d'accord

Moi j'y comprends rien à cette DSA: si le PRNG d'openssl repose uniquement sur de la mémoire pas initialisée plutôt que sur des choses comme /dev/random alors c'est openssl qu'il faut jeter.

ouais alors là je suis bien d'accord avec toi. Le non-initialisé, ça peut souvent contenir que du 0 ou un motif, quelque chose de très prévisible justement. Les dev d'openssl a part vaner sur debian ne font pas de véritable analyse du problème. ça sent vraiment mauvais openssl.

 
ça c'est un truc que je capte pas : on a des crypto devices, et on ne s'en sert pas...

L'excuse c'est la portabilité j'imagine, utiliser le maximum de code commun sur toutes les plates-formes est censé apporter plus de sécurité.

je croyais que debian voulait balancer openssl pour des problèmes de licences, il y a peut être pas que ça en fait.
C'est une escroquerie cette alerte: je vois pas en quoi dépatcher le bouzin corrige le problème de sécurité. Bien malheureux ceux qui se croient à l'abri avec du code comme ça.

Je viens de pinger sur http://bugs.debian.org/cgi-bin/bug [...] bug=363516 pour avoir des infos.

 
A d'autres... Tous les unix ont des /dev/*random*...

C'est sinistrement stupide comme approche.

Salut les gens,

Bon voila, je n'arrive pas à bien estimer le risque ...
Est ce si grave ?
Est ce rapide de compromettre une connexion ssl ? (par exemple https  ou ssh via mot de passe) ?

D'après Black lord tout ca est très théorique ?

Car regénérer les clefs de tout les serveurs va me prendre du temps beaucoup de temps (voir trop) :
- sshd (que la connexion soit par mot de passe ou par clef)
- openvpn
- certificats https

Bah on est comme toi, on ne sait pas quoi penser. La DSA ne donne pas d'indice sur la faisabilité d'une attaque, et surtout quand on voit le correctif/dépatch, on se met à penser que patch ou pas, les clefs/certificats générés avec openssl sont de qualité extrêmement médiocre.

Openssl doit être dispo sur windows ?
Enfin ca empêche pas d'utiliser une source en plus la ou elle est disponible...

 
http://wiki.debian.org/SSLkeys
 
ça ne prends qu'une minute/serveur avec des scripts...

je voulais tester mes clefs ...  

J'ai cherché un peu plus d'infos, et apparement ça vient de ce patch: http://svn.debian.org/viewsvn/pkg- [...] /md_rand.c
 
Le problème est donc, si j'ai bien compris, dans l'ajout de données au buffer d'entropie utilisé pour seeder le PRNG.  
 
En bas, il y a l'ajout de données non-initialisées pour rendre cette seed un peu plus aléatoire parce que ça ne peut qu'améliorer le truc, mais on remarque qu'il y a un #define autour pour dégager les warnings de Valgrind ou Purify. Plutôt que de setter le flag pour dégager cette partie via le define, la personne qui a créé le patch a tout commenté. Ce bout de code ne sert qu'à rendre le pool un peu plus aléatoire, et dans tous les cas ça ne peut pas le rendre moins aléatoire.
 
Mais en haut, c'est d'après les explications que j'ai eu un ajout d'un buffer initialisé et essentiel à un seeding correct du PRNG.
 
http://www.links.org/?p=327:

 
Pour le détecteur de clés fuckées, il est dans le premier lien, c'est http://security.debian.org/project [...] owkd.pl.gz
 
edit: une autre explication assez complète:

 
teste plutôt tes hosts

http://bugs.debian.org/cgi-bin/bug [...] bug=363516
 
Je suis désolé, mais je ne vois pas en quoi il y a un problème de sécurité. Soit le rôle de ce buffer pas initialisé est minime et ça n'a pas d'impact qu'il soit utilisé ou pas, ou qu'il ait une valeur fixe et connue, soit son rôle n'est pas minime et là le problème est plus grave.
 
Le gars de Debian dit que la sécurité d'openssl ne repose pas ce buffer pas initialisé.
 
Je ne vois pas la logique dans toutes les conclusions "jetez vos clefs". Est-ce que les clefs regénérées seront vraiment meilleures ?

Voir mon post de clarification

 
 
http://wiki.debian.org/SSLkeys  > How weak?  

Et pour la première partie du post, tout à la fin, "A bit more detail" (qui dit à peu près la même chose que mon post)

OK, ça commence à être clair.

En gros, en voulant faire du nettoyage, le développeur debian a:
- supprimé un morceau de code qui utilise un buffer pas initialisé. c'est pas grave puisque ce buffer est un buffer de sortie. ça ne modifie pas sensiblement la quantité d'entropie. Ca se passe dans ssleay_rand_bytes .
- supprimé un morceau de code similaire mais qui se coup si n'est pas un fignolage mais la base d'entropie du PRNG. ça se passe dans ssleay_rand_bytes. Et c'est là le problème de sécurité: le vecteur d'initialisation n'est pas utilisé.

La où est l'erreur, c'est que le bout de code est identique, mais avec un usage radicalement différent.

 
C'est le .pub qu'il faut lui donner

tous mes serveurs sont à jour, toutes mes clés ont été changées

Vu que personne ne vérifie jamais les fingerprint de ses serveurs, j'imagine le carton possible.

qu est ce que j ai encore mal  fait ?

tu as mal lu la doc

 
euh cad ?
 

http://wiki.debian.org/SSLkeys

http://lists.debian.org/debian-sec [...] 00153.html checklist du chemin d'update

Tu la crée ou pas ?
 

chez moi ça marche

problème de cache