faille openssl debian

Le
mpg
Bonjour,

Savez-vous où l'on peut trouver plus d'infos sur la faiblesse du générateur
pseudo-aléatoire qui était présente jusqu'à hier dans les versions
debianisées d'openssl ?

http://lists.debian.org/debian-security-announce/2008/msg00152.html

Notament, à quel points les clés produites étaient-elles prédictibles ?
A-t-on une estimation de la diminution d'entropie du générateur et est-elle
suffisante pour autoriser des attaques par force brute ?

Manuel.
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
A. Caspis
Le #6626751
mpg wrote:
Savez-vous où l'on peut trouver plus d'infos sur la faiblesse du générateur
pseudo-aléatoire qui était présente jusqu'à hier dans les versions
debianisées d'openssl ?


D'après ce qu'on peut lire un peu partout, Debian aurait ajouté à
OpenSSL ce patch qui a pour effet de réduire l'entropie du générateur
pseudo-aléatoire:

http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?p2=%2Fopenssl%2Ftrunk%2Frand%2Fmd_rand.c&p1=openssl%2Ftrunk%2Frand%2Fmd_rand.c&r11&r20&rev1&view=diff&diff_format=c


Notament, à quel points les clés produites étaient-elles prédictibles ?


D'après http://wiki.debian.org/SSLkeys :

It looks likely that the only remaining source of entropy in the
generated keys comes from the PID of the process. This is 16 bits,
typically much less effective entropy.


Par ailleurs le script Perl mentionné dans votre lien a l'air de contenir
des hash des clés concernées - ils doivent bien venir de quelque part...

Si tout ça est vrai, c'est dramatique, et les organisations qui auraient
pris la peine d'archiver du trafic chiffré intercepté depuis mai 2006
doivent bien rigoler.

Voir par exemple les mesures drastiques que les gens de Debian eux-mêmes
ont pris pour limiter les dégâts dans leur infrastructure:
http://lists.debian.org/debian-devel-announce/2008/05/msg00003.html

AC

Al
Le #6628011
p'tain,

la première fois que j'ai vraiment les pétoches...
dans les jours qui viennent des filou vont scanner tout les points
d'entrée SSH des machines de prod de divers services hébergés sur du
debian... et si l'upgrade n'a pas été fait et les clés regénérées...

même ma petite soeur munie d'un script pourrait accéder à des SSH connus.

8((( le type même de "class break"
mpg
Le #6628001
Le (on) mercredi 14 mai 2008 21:03, A. Caspis a écrit (wrote) :

D'après http://wiki.debian.org/SSLkeys :

It looks likely that the only remaining source of entropy in the
generated keys comes from the PID of the process. This is 16 bits,
typically much less effective entropy.


Wouch ! Ça fait très mal en effet. Merci pour le lien, j'avais pourtant

survolé cette page du wiki mais n'avais vu que les infos utilisateur (quoi
et comment mettre à jour)...

Par ailleurs le script Perl mentionné dans votre lien a l'air de contenir
des hash des clés concernées - ils doivent bien venir de quelque part...

Et visiblement il y en a environ 250 000, toutes tailles de clés confondues,

ce qui est bien peu.

Si tout ça est vrai, c'est dramatique, et les organisations qui auraient
pris la peine d'archiver du trafic chiffré intercepté depuis mai 2006
doivent bien rigoler.

Euh, je connais pas très bien SSL, mais les annonces parlaient beaucoup des

clés asymétriques : est-ce que les clés de sessions (symétriques) sont
touchées aussi ? Ou bien est-ce qu'on peut les récupérer dès qu'on connaît
la clé privée de chacun des interlocuteurs ?

Voir par exemple les mesures drastiques que les gens de Debian eux-mêmes
ont pris pour limiter les dégâts dans leur infrastructure:
http://lists.debian.org/debian-devel-announce/2008/05/msg00003.html

Yep, c'est en fait pas ce biais que j'ai appris le truc (puis par un cron

qui m'a dit que des mises à jour étaient en attente sur ma machine etch).
J'étais un peu surpris par l'ampleur des mesures et me demandais si c'était
un excès de prudence ou si la faille était vraiment si terrible.
Visiblement, c'était le 2 :-(

Manuel.


A. Caspis
Le #6628621
mpg wrote:
Euh, je connais pas très bien SSL, mais les annonces parlaient beaucoup des
clés asymétriques : est-ce que les clés de sessions (symétriques) sont
touchées aussi ? Ou bien est-ce qu'on peut les récupérer dès qu'on connaît
la clé privée de chacun des interlocuteurs ?


Le scénario qui m'inquiète est celui où un client sans certificat
s'est connecté depuis 2006 à un serveur SSH ou HTTPS à clé faible.

D'après http://en.wikipedia.org/wiki/Secure_Sockets_Layer
In order to generate the session keys used for the secure connection,
the client encrypts a random number with the server's public key,
and sends the result to the server. Only the server can decrypt it
(with its private key): this is the one fact that makes the keys
hidden from third parties, since only the server and the client have
access to this data.


Si la clé privée du serveur est faible, le nombre aléatoire en question
("premaster secret") n'est plus secret.

Même si il y a du Diffie-Hellman derrière, dans le cas où le serveur
a un PRNG faible, un attaquant peut potentiellement récupérer le g^a
envoyé par le client et calculer (g^a)^b en énumérant b.

Il y a aussi le scénario où le client *et* le serveur ont des PRNG
faibles. Dans ce cas l'attaquant peut potentiellement trouver la clé
de session, même si la clé privée a été générée sur une machine non
affaiblie (par exemple avant 2006).

Espérons que les experts confirmeront ou infirmeront bientôt (mais en
ce moment ils doivent être tous occupés à colmater les brèches).

AC

Erwan David
Le #6628921
"A. Caspis"
mpg wrote:
Euh, je connais pas très bien SSL, mais les annonces parlaient beaucoup des
clés asymétriques : est-ce que les clés de sessions (symétriques) sont
touchées aussi ? Ou bien est-ce qu'on peut les récupérer dès qu'on connaît
la clé privée de chacun des interlocuteurs ?


Le scénario qui m'inquiète est celui où un client sans certificat
s'est connecté depuis 2006 à un serveur SSH ou HTTPS à clé faible.


Il y a aussi les partitions chiffrées : dm-crypt ou encfs utilisent-ils
openssl ?

--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé


Jean-Marc Desperrier
Le #6629291
A. Caspis wrote:
[...]
Le scénario qui m'inquiète est celui où un client sans certificat
s'est connecté depuis 2006 à un serveur SSH ou HTTPS à clé faible.
[...]


Pour HTTPS le fait que le client ait un certificat ne change rien (Ce
qui change vraiment quelquechose, c'est que si un protocole DH est
utilisé, le chiffrement sera de qualité sauf si le serveur ET le client
ont un chiffrement faible. Firefox avec un apache va utiliser du
DH/AES256 par défaut, pas IE)

Pour SSH, c'est une référence au risque que sans certificat son mot de
passe soit capturé en plus de déchiffrer la session ?

J'espère en tout cas que cet énorme plantage puisse avoir en conséquence
un changement de philosophie sur la manière dont les dév Debian
introduise des patch sur les logiciels dans leur distrib, qu'ils se
donnent la peine de faire des vrais retours upstream, et qu'ils
développent quelques réflexes d'évaluation de la sensibilité du patch
(je m'apprète à patcher le *générateur* *aléatoire* d'une librairie
crypto, est-ce que c'est sensible, est-ce que j'ai intérêt de m'entourer
du *maximum* du précaution ? Est-ce que j'ai bien mentionné en en
parlant que je suis développeur Debian, que le changement va se
retrouver dans la package standard et qu'il ne s'agit pas juste de
déboguer mon appli à la maison ? J'ai mis juste 1 ligne de contexte, par
exemple chez Mozilla ils ont standardisé le fait d'en mettre 10, c'est
juste pour s'amuser à alourdir les patch ou bien ça servirait à
quelquechose des fois ?)

A. Caspis
Le #6629811
Jean-Marc Desperrier wrote:
Pour HTTPS le fait que le client ait un certificat ne change rien (Ce
qui change vraiment quelquechose, c'est que si un protocole DH est
utilisé, le chiffrement sera de qualité sauf si le serveur ET le client
ont un chiffrement faible. Firefox avec un apache va utiliser du
DH/AES256 par défaut, pas IE)


Même si les deux participants supportent DH/AES256, n'y a t-il pas un
risque si le PRNG qui génère un des deux exposants DH est faible ?
(CF l'attaque suggérée plus bas dans le message auquel vous répondiez)


Pour SSH, c'est une référence au risque que sans certificat son mot de
passe soit capturé en plus de déchiffrer la session ?


Pour SSH comme pour HTTPS, je m'intéressais aux conséquences de cette
affaire pour les gens qui comme moi ne travaillent pas sous Debian
mais peuvent être amenés à se connecter à des machines affectées.

En plus du déchiffrement a posteriori que l'on ne peut pas empêcher,
il faudra en effet changer ses mots de passe sur les serveurs SSH et
sites web concernés, pour éviter des attaques futures.
Et peut-être charger une CRL de 262144 entrées dans son navigateur :)

AC

Jean-Marc Desperrier
Le #6630121
A. Caspis wrote:
[...]
Même si les deux participants supportent DH/AES256, n'y a t-il pas un
risque si le PRNG qui génère un des deux exposants DH est faible ?
(CF l'attaque suggérée plus bas dans le message auquel vous répondiez)


Oui désolé, je n'avais pas bien lu cette partie. On connait le "g^b mod
p" envoyé par le serveur ; si le nombre de valeurs pour b est
suffisament faible pour les énumérer et refaire ce calcul pour toutes,
on peut retrouver laquelle a été utilisée et casser le dh.

Il y a une mitigation pour un serveur par rapport à la génération de clé
car on ne vient pas de le lancer immédiatement avant de lui demander
cette valeur, mais bon :-( Il semble le plus probable que cela ne fasse
qu'augmenter un peu le temps de calcul avant de trouver le bon b en
obligeant pour chaque état initial possible du générateur aléatoire à
prendre en compte les quelques dizaines, ou centaines de valeurs
suivantes qui vont être générées.

Al
Le #6634441
A. Caspis wrote:

Pour HTTPS le fait que le client ait un certificat ne change rien (Ce
qui change vraiment quelquechose, c'est que si un protocole DH est
utilisé, le chiffrement sera de qualité sauf si le serveur ET le client
ont un chiffrement faible. Firefox avec un apache va utiliser du
DH/AES256 par défaut, pas IE)


le gros risque c'est que la clé de session soit faible.

je ne sais pas si le générateur aléatoire en cause est utilisé pour la
clé de session

SSL, comme les autres protocoles hybrides, est dépendant de la faiblesse
de la crypto publique, et de la crypto privée... si l'un des 2 est
faible, tout saute.

ainsi si la clé de session est faible, pas besoin de déchiffrer le RSA
ou le DH, il suffit de déchiffrer le DES ou l'AES avec quelques milliers
de clés non aléatoires.

donc, si quelqu'un a mémorisé des flux SSL, il pourra les déchiffrer

Publicité
Poster une réponse
Anonyme