C'est le syndrome OpenSSH de Debian qui frappe une nouvelle fois.
Du fait d'une parenthèse mal placée dans le code du fichier /src/sys/kern/subr_cprng.c, il s'avère que le générateur pseudo-aléatoire de NetBSD 6.0 est bien moins solide que ce qui était attendu.
C'est une manière polie de dire que sa sortie n'est pas assez aléatoire et qu'il faut d'urgence changer les clés SSH qui ont été générés avec ce noyau !
L'alerte de sécurité : http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2013-003.txt.asc
Un article de h-online : http://www.h-online.com/open/news/item/Weak-keys-in-NetBSD-1829336.html
Le problème est corrigé dans NetBSD Current et le fix sera disponible dans la furture version NetBSD 6.1.
Il est probable que les dégâts seront bien moins étendus que lors de l'affaire OpenSSH dans Debian car les systèmes NetBSD 6.0 ne sont sans doute pas très fréquents dans la nature.
# Des détails
Posté par wolowizard . Évalué à 6. Dernière modification le 25 mars 2013 à 16:03.
Bonjour,
Le bug reste sérieux mais ce n'est pas le même passif que le bug introduit dans OpenSSL par Debian,non? (je ne suis pas expert en sécurité).
D'une part le bug Debian a couru pendant deux ans, avec une possibilité de génération de clés assez faible ( 25000 en gros selon la news).
Si je lis le Netbsd Security Advisory, les systèmes de la version 6.0 générés avant le 27 Janvier 2013 sont impactés. La version 6.0 est sortie courant mi-octobre 2012. Ce qui fait une correction en moins de deux ans, si je ne m'abuse.
Pour palier à ce problème de parenthèses mal placées, il est nécessaire d'installer un noyau contenant le fix construit après le 27 Janvier.
Le Netbsd Security signale au pire la génération de clés de 32 bits sur certaines plate-formes, avec "plus a 32-bit cycle counter value, plus the name of the generator(an LWP ID for userspace, a fixed string for kernel consumers),plus stack noise for the remainder." Cette phrase, je ne la comprends guère, donc si quelqu'un la comprend ou a des explications à fournir ( ou des liens pertinents), je serai preneur.
[^] # Re: Des détails
Posté par kursus_hc . Évalué à 4.
Désolé de faire mon grammar n*zi, mais on dit "palier un problème".
Un bon moyen pour s'en souvenir est de remplacer le mot par son sens originel : "recouvrir". On dira "recouvrir un problème", le faire disparaître.
[^] # Re: Des détails
Posté par wolowizard . Évalué à 10.
Merci, je suis content d'être corrigé. Me redresser sur ce genre de fautes me forcera à une seconde relecture.
D'autant plus que c'est "pallier un problème" et non "palier". "Palier" étant une plate-forme, un étage.
# outil de mesure ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
A quand un outil de vérification de ces générateurs aléatoires ?
"La première sécurité est la liberté"
[^] # Re: outil de mesure ?
Posté par ckyl . Évalué à 3.
A quand les devs noyau se mettront au TDD plutôt qu'à code hero ? ;)
[^] # Re: outil de mesure ?
Posté par reno . Évalué à 1.
A peu près au même moment qu'ils se mettront à coder en le noyau en Ada(*) plutôt qu'en C?
*: Non, Ada ne permettrait pas de trouver ce problème particulier, mais plein d'autre..
[^] # Re: outil de mesure ?
Posté par Enj0lras . Évalué à 4.
Le jour ou l'on recodera 12millions de lignes de code de C vers ada, en perdant tout l'historique et les corrections de bugs réalisées depuis 30ans, on aura forcément un truc plus stable.
Faut pas non plus croire que coder en Ada supprime tout les bugs… D'accord c'est plus simple à prouver, mais c'est pas évident que recoder un noyau en Ada soit un bénéfice sinon à trés long terme (10ans ?). A moyen terme, des choses comme seL4 sont sûrement beaucoup plus prometteuses.
[^] # Re: outil de mesure ?
Posté par Maxime (site web personnel) . Évalué à 10.
Pour vérifier, regarde :
http://en.wikipedia.org/wiki/Diehard_tests et http://fr.wikipedia.org/wiki/Test_du_%CF%87%C2%B2
En vrai :
[^] # Re: outil de mesure ?
Posté par neil . Évalué à 0. Dernière modification le 25 mars 2013 à 18:25.
Tu peux aussi lire ce que les spécialistes pensent de Diehard :
Plus bas, il explique que Diehard et NIST sont obsolètes dès qu’on a besoin de billions de nombres aléatoires, auxquels cas il faut recourir à Crush et BigCrush en sus. Pour des trucs pas sérieux comme la simple génération de clés, ce genre de tests importe peu.
# C'est peut-être con, mais…
Posté par navaati . Évalué à 1.
Un noyau génère des clef SSH ? Uh ?
[^] # Re: C'est peut-être con, mais…
Posté par ckyl . Évalué à 10.
Non mais il génère des bits aléatoires, qui eux servent à SSH pour générer les clés. Et c'est bien la le problème.
man 4 random# Que les clefs SSH ?
Posté par jben . Évalué à 10. Dernière modification le 25 mars 2013 à 21:29.
Il y a une raison particulière pour laquelle SSH serait seul touché ? Moi dit comme ça j'aurai tendance à considérer toutes les clefs cryptographiques générés sur une machine ayant ce noyau comme faible.
[^] # Re: Que les clefs SSH ?
Posté par MrLapinot (site web personnel) . Évalué à 2.
Toutes les clefs générées en utilisant /dev/urandom. Peut-être que les autres bibliothèques utilisent /dev/random directement pour générer leurs clefs ?
[^] # Re: Que les clefs SSH ?
Posté par ckyl . Évalué à 5.
Ca me ferait un peu peur que quelqu'un utilise
/dev/urandompour des besoins cryptographiques. Je viens de regarder le code d'OpenSSH:Pour OpenSSH, il utilise arc4random et donc
/dev/arandom.Pour OpenSSH portable il repose sur
/dev/random. Il existe une possibilité d'utiliser PRNGd si il n'y a pas de/dev/randomou si on le choisi.# Code snippet ?
Posté par calandoa . Évalué à 5.
Quelqu'un a-t-il compris cette histoire de parenthèse ? J'ai essayé de trouver le morceau de code en question, mais sans succès.
[^] # Re: Code snippet ?
Posté par patate . Évalué à 8.
Sur le diff (http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/subr_cprng.c.diff?r1=1.14&r2=1.15&only_with_tag=MAIN&f=h), pour la partie concernant la ligne 183:
rnd_extract_data(key + r, sizeof(key - r), RND_EXTRACT_ANY);
Le deuxième paramètre devrait être
sizeof(key) - r.Dans la version 1.15, cette appel a été déplacé (et corrigé) vers la nouvelle fonction
cprng_entropy_try.A moins qu'il n'y aie un détail qui m'aie échappé.
[^] # Re: Code snippet ?
Posté par calandoa . Évalué à 1.
Bien vu ! j'avais regardé le même diff, sans pourtant remarquer où était l'erreur…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.