Liens connexes

Dépêche modérée par

Dépêche éditée par

: Découverte d'une faille de sécurité critique dans OpenSSL de Debian

Posté par Amaury (). Modéré le 15 mai 2008.
0
Le 13 mai, un message publié sur la liste de sécurité Debian identifiait une anomalie impactant le paquet openssl. Ce bug a été introduit par un mainteneur Debian, qui a eu la main lourde en voulant "corriger" des alertes remontées par Valgrind (un logiciel qui audite le code). Résultat des courses : le générateur de nombres aléatoires, composant critique de nombreux systèmes de chiffrements, n'est au final pas si aléatoire que ça, voire carrément prévisible.
En conséquence, tous les certificats et clefs SSL/SSH générés sur une Debian (ou dérivée) depuis 2006 l'ont été à partir d'un univers des possibles très restreint (environ 250 000 clefs, à confirmer) et présentent donc un niveau de sécurité largement inférieur à celui estimé.

Cette vulnérabilité touche Debian ainsi que toutes les distributions utilisant des paquets Debian (Ubuntu, Xandros...).

Pour prendre un exemple parlant, imaginez Securor, un fabricant de serrures qui seraient utilisées un peu partout sur la planète. Au bout de deux ans, alors que des millions de personnes ont installé des serrures pour protéger leur maison, on se rend compte qu'en fait il n'existe que 3 modèles uniques de clefs, les autres ne sont que des copies d'un des 3 modèles d'origine. Si bien qu'un voleur peut très facilement concevoir un trousseau contenant les 3 modèles de clefs, en ayant la certitude que toute serrure rencontrée pourra être ouverte avec l'une de ces clefs...

Concrètement, si vous utilisez une Debian, ou dérivée, vos VPN peuvent être cassés (adieu confidentialité des échanges), des faux certificats peuvent être signés (adieu confiance en votre système de PKI), votre serveur SSH ne filtre plus grand monde (adieu système sécurisé)...

Que faire ?
  1. Mettre à jour votre distribution Debian pour installer les nouveaux paquet.
  2. Vérifier sur tous vos systèmes qu'une clef faible n'est pas présente. Pour cela, un outil est disponible : dowkd.pl
    Si une clef faible est présente, il sera nécessaire de la générer à nouveau, avec tous les impacts que cela peut avoir (fichiers authorized_keys & know_hosts obsolètes...). Même problème pour les certificats : j'espère que personne n'a mis en place de PKI sous Debian depuis 2006, il va falloir regénérer les certificats...
  3. lire le wiki Debian http://wiki.debian.org/SSLkeys qui vous guidera pas à pas en fonction des logiciels installés sur votre machine.
Reste à savoir quelles seront les conséquences de cette affaire : depuis 2 ans, un bug introduit par un contributeur et impactant un système critique est resté indétecté dans une des distributions les plus utilisées au monde...

NdM : lire également les articles sur Planet Debian-Fr.

> Lire les commentaires (329 commentaires, moyenne: 2,2).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Fiabilité de dowkd.pl ...

Posté par GnunuX (Jabber id, page perso, ) le 15/05/2008 à 14:00. (lien). Évalué à 10.

> Pour cela, un outil est disponible : dowkd.pl

Je rappelle quand même ce que dit le wiki :

> Note that dowkd.pl produces many false positives and that the authors suggest
> that it may also produce false negatives. On that basis, you might decide that it is
> simply easier to regenerate your keys as described above.

En gros, il faut avoir autant de confiance en dowkd.pl qu'a l'ancienne version d'openssl. Bref, faut TOUT regénérer.

debian

Posté par maggic (page perso, ) le 15/05/2008 à 14:01. (lien). Évalué à 10.

debian sapu saipahaleatoire.

Un peu d'humour

Posté par plusplus () le 15/05/2008 à 14:03. (lien). Évalué à 8.

Voilà deux dessins très drôles postés par un contributeur KDE sur son blog à propos de générateurs aléatoires :
http://daniel.molkentin.de/blog/archives/118-On-the-topic-of(...)

fail2ban

Posté par Putifuto () le 15/05/2008 à 14:05. (lien). Évalué à 9.

d'ou l'intérêt de bannir les possibilités d'attaques à la force brute.

des contres mesures genre fail2ban http://www.fail2ban.org/wiki/index.php/Main_Page qui bloque l'accès après X tentatives échouées sont toujours intéressantes à mettre en place.

--
http://linuxfr.org/board <-- des moules, du sang, de la violence

Debian ou dérivé

Posté par Romain Bignon (Jabber id, page perso, ) le 15/05/2008 à 14:16. (lien). Évalué à 2.

Je trouve que la dépêche met trop l'accent sur Debian, il n'y a qu'une seule indication dedans concernant la vulnérabilité des distributions basées sur Debian :

En conséquence, tous les certificats et clefs SSL/SSH générés sur une Debian (ou dérivée) depuis 2006 l'ont été à partir d'un univers des possibles très restreint (environ 250 000 clefs, à confirmer) et présentent donc un niveau de sécurité largement inférieur à celui estimé

Perdu comme ça au milieu d'un paragraphe hors sujet, je trouve ça insuffisant.

Avec ça, les utilisateurs des distributions telles que Ubuntu, Xandros (eeepc), et autres, ne vont pas prendre l'alerte au sérieux.

Mise en perspéctive

Posté par Romain Be. () le 15/05/2008 à 14:17. (lien). Évalué à 10.

Reste à savoir quelles seront les conséquences de cette affaire : depuis 2 ans, un bug introduit par un contributeur et impactant un système critique est resté indétecté dans une des distributions les plus utilisées au monde...

Attention à mettre en perspéctive ce genre d'affirmation.

Ce bug est important, voire très grave c'est clair.

Cependant, il en existe d'aussi important, voire peut-être plus, qui ne sont pas revélés et encore moins corriger (je ne citerai pas d'OS...).

Debian a choisi de communiquer intensément, dans la tradition d'"on ne cachera pas les problèmes". C'est aussi important que la faille soit fixée rapidement ainsi que publiquement expliquée, y compris sur les façon de s'en proteger.

Et pour cela, c'est positif il me semble.

--
If you are the big tree,
We are the small axe...

utilisation dowkd.pl

Posté par korm () le 15/05/2008 à 14:28. (lien). Évalué à 1.

Bonjour,

J'utilise pour mes serveurs une ubuntu dapper (je présume qu'elle est affectée par le bug). Je me demande comment utiliser correctement dowkd.pl, pour ne pas refaire toutes les clés.

J'ai installé openvpn et j'avais créé à l'époque des fichiers
.crt qui commencent par --- begin certificate --
.key qui commencent par --- begin rsa private key ---

j'ai pour le serveur apache2 plein de fichier .pem. J'avais créé les certificats avec apache2-ssl-certificates

Je me demandais quel genre de fichier dowkd.pl doit lire (les .pem, les .crt, les .key?). Je suppose que ce sont ceux en .key (avec la clé privée rsa),mais j'en suis pas sûr.

Merci.
Quentin

[+] Limite du développement bénévole

Posté par Unixfix le Gaulois () le 15/05/2008 à 14:33. (lien). Évalué à -9.

Au risque d'apparaitre iconoclaste, les professionnels utilisant Debian et ses dérivés devraient pourtant savoir que Debian n'en est pas à son premier gros problême de sécurité.

Il n'y a pas si longtemps pendant un mois il n'y avait pas eu de mise à jour de sécurité, car le responsable n'était pas disponible.

Debian étant une distribution communautaire elle est dépendantes des bonnes volontés.

Dans le cas d'openSSL le mainteneur a fait plus par ignorance combiné avec un problème sérieux de communication que par mauvaise volonté une énorme bêtise.

La aussi Debian montre les limites du développement bénévole. Il n'y a visiblement pas la possibilité de mettre plusieurs mainteneurs sur des paquets dits "sensibles"

Les distributions commerciales dérivées de Debian sont encore plus coupables. Ayant plus de moyen surtout celles visant la clientèle professionnelle devraient contrôler les paquets sensibles pour la sécurité. Elles ne l'ont pas fait. J'espère pour elles que cela n'aura pas trop de conséquence sur leur avenir commercial

Pour finir aux tenant de la gratuité : la sécurité peut être libre mais ele n'est pas gratuite….

--
Slackware depuis 1996