lundi 30 août
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

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 () 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….

--
D' Unix à Linux sans passer par Redmond...

Le problème OpenSSL dans Debian et ses dérivés vu par Roland Mas

Posté par GeneralZod () le 15/05/2008 à 14:55. (lien). Évalué à 2.

Roland Mas Développeur Debian a écrit un billet sur la question.
Bonne lecture !
http://roland.entierement.nu/blog/2008/05/15/branle-bas-sshs(...)

Liste des clés possibles

Posté par Olivier Tétard (Jabber id, page perso, ) le 15/05/2008 à 15:03. (lien). Évalué à 10.

Résultat des courses : le générateur de nombre 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 effet, c'est carrément prévisible, le seul bout d'aléa étant le numéro du processus (qui est codé sur 15 bits), cela fait 32 767 clés possibilités... Ce qui s'avère très peu.

Les clés possibles de 1024, 2048 et 4096 ont été générés par H D Moore : [http://metasploit.com/users/hdm/tools/debian-openssl/]. Il ne reste donc plus qu'à tester toutes les clés.

À lire aussi, mais en anglais : http://blog.drinsama.de/erich/en/linux/2008051401-consequenc(...)

Olivier;

Est-ce que quelqu'un saurait pourquoi

Posté par équi () le 15/05/2008 à 15:58. (lien). Évalué à 3.

OpenSSL n'utilise pas /dev/random (ou équivalent) pour générer ses nombres aléatories ?

Une réaction sur Debian Planet en français

Posté par Amaury () le 15/05/2008 à 19:13. (lien). Évalué à 10.

Avant-propos : je ne connais pas l'auteur des propos ci-dessous ni son rôle au sein de la communauté. Je sais en revanche que je vais passer mon week-end à reparamétrer un paquet de trucs impactés par cette vulnérabilité sur les serveurs dont je m'occupe et que mon propos est donc justifié.

Je lis sur http://planet-fr.debian.net/ un post de Roland Mas intitulé "Branle-bas SSH/SSL" publié le 15 mai. Ce message, assez clair par ailleurs sur le fait que les conséquences de cette vulnérabilité dépassent largement le cadre de la simple distribution Debian (et dérivées) puisque les clefs et certificats pourris ont pu être copiés un peu partout ailleurs, ce message donc est présenté comme un rectificatif des informations incorrectes ayant pu être publiées ci et là.

Et il présente donc fort à propos l'origine du problème de la façon suivante : "Le cœur du problème : pour des raisons tout-à-fait légitimes, et suite à une mauvaise communication avec les auteurs amont d'OpenSSL, les versions d'OpenSSL (...) utilisaient un générateur de nombres pseudo-aléatoires (...) absolument pas aléatoire."

Soit j'ai mal compris la phrase ci-dessus, soit Roland est en train de nous expliquer qu'une faille de sécurité majeure, impliquant l'un des systèmes de sécurité les plus utilisées au monde (SSH, PKI, VPN), qui risque de mettre gravement en cause la crédibilité du logiciel libre aux yeux de pas mal de monde, et accessoirement qui va me faire perdre mon week-end à mettre à jour les nombreuses machines dont j'ai la charge, cette faille de sécurité donc a été introduite pour des raisons tout à fait légitimes.
Vous verrez, dans 2 jours il va nous sortir qu'en fait "it's not a bug, it's a feature".

J'ai du mal à voir les "raisons légitimes" qui justifieraient qu'un contributeur touche à un composant critique au petit bonheur la chance pour faire plaisir au debuggeur et que personne n'y trouve rien à redire.

[+] Tous ces commentaires sont désolants ...

Posté par Michel Rodriguez () le 15/05/2008 à 22:10. (lien). Évalué à -3.

... Pour plein de raisons (énoncées ici et là mais bon...) :
1) le zéro défaut, c'est un mythe. Voire : plus c'est gros, plus ça passe. Rappelez-vous un certain Jérome K
2) Vous trouvez Debian nulle ? Utilisez Windows et bouclez-là.
3) Que ceux qui ont déjà remonté un patch (digne de ce nom) à Debian dans ce forum lèvent le doigt les autres, voir le point 2)
4) Pour les plus paranos : quoi ? vous avez installé sur vos serveurs chéris un paquet que vous n'avez pas personnellement testé ? c'est suspect...

Très franchement, c'est fatiguant. Imaginez ce qui trotte dans la tête des DD aujourd'hui : "Je suis une grosse merde...". Bossant à la SG, je suis passé par là, j'imagine ce qu'ils ressentent.

Allez plutôt les soutenir de la manière qui vous paraît la plus appropriée pour vous, ça leur fera du bien.

Difficulté de créer un bon générateur de nombres aléatoires (ou pas

Posté par Victor STINNER (Jabber id, page perso, ) le 15/05/2008 à 23:08. (lien). Évalué à 2.

Netscape, stunnel, l2tpd, ClamAV, serveur NFS, Kerberos, les implémentations du protocole TCP, etc. ont tous eu leurs lots de bugs dans leurs générateurs de nombres pseudo aléatoires. Plus récemment, c'est Bind et le serveur DNS de Microsoft qui ont eu des soucis. Encore plus récemment, c'est carrément des bugs dans les générateurs de Linux et de Windows qui ont été trouvés...
http://www.haypocalc.com/blog/index.php/2007/12/02/96-bugs-g(...)

J'avais regardé un peu pour BIND8, et en fait l'implémentation du double générateur à base registre à décalage était correcte, mais le développeur s'était trompé en recopiant un des deux polynômes utilisés (du livre de Bernstein). Oups :-)

Bon, ok, le bug openssl est un peu plus critique (quoique, TCP et Kerberos, on s'en soucie un petit peu quand même) car on se croit protégé derrière une armée d'algorithmes et de théories de mathématiques... Sauf que l'erreur est humaine et personne n'est à l'abri d'un bug.

Discussion avec upstream sur la suppression des lignes incriminées

Posté par François B. () le 15/05/2008 à 23:44. (lien). Évalué à 1.

Globalement, je suis plutôt d'accord avec ceux qui trouvent que le DD doit discuter avec upstream avant de faire une modification qui peut être très sensible... et c'est ce qu'il a fait !

http://marc.info/?l=openssl-dev&m=114651085826293&w=(...)

Le message a été posté sur openssl-dev, et contient à la fin, après avoir exposé ses découvertes avec Valgrind et les deux lignes incriminées (l'emphase est de moi) :
What I currently see as best option is to actually comment out
those 2 lines of code. But I have no idea what effect this
really has on the RNG. The only effect I see is that the pool
might receive less entropy. But on the other hand, I'm not even
sure how much entropy some unitialised data has.

What do you people think about removing those 2 lines of code?

Donc, contrairement à ce que je peux entendre un peu partout, le développeur savait qu'il y avait un impact sur l'entropie du générateur. Mais bon, je vous laisse parcourir le fil de discussion, il n'y a eu que trois réponses qui sont également en faveur de la suppression (mise en commentaire ou compilation conditionnelle) des deux lignes.

Premiers cas de collisions de clés...

Posté par snt () le 16/05/2008 à 00:04. (lien). Évalué à 4.

Lu sur github ( herbergement de dépots git ) : "we identified several cases where different users (with no knowledge of each other) generated the same public keys. We’ve notified all parties and revoked the keys. All instances of this were caused by keys generated on Ubuntu."

-> Traduction à l'arrache : Nous avons identifiés plusieurs cas où différents utilisateurs ( ne se connaissant pas ) ont généré les memes clés publiques. Nous les avons informés et révoqué les clés. Les clés incriminées ont été générées avec Ubuntu.

http://github.com/blog/63-ssh-keys-generated-on-debian-ubunt(...)

Dilbert

Posté par IsNotGood () le 16/05/2008 à 00:28. (lien). Évalué à 2.

Mort de rire :
http://dilbert.com/strips/comic/2001-10-25/

Feature ! blink blink !!

Posté par IsNotGood () le 16/05/2008 à 04:21. (lien). Évalué à 7.

Debian la distribution la plus sûr.

http://blog.drinsama.de/erich/en/linux/2008051401-consequenc(...)
In fact, if your server is running Debian and you installed the Debian security update for openssh, it will be much more secure than the RedHat server. Because the Debian server has a blacklist of keys that are too common. The other-Linux server who doesn't have this blacklist doesn't know that a certain 'weak' key is not trustworthy.

Mais qu'elles sont nulles les autres distributions.

1 minute (pas plus) de compassion

Posté par oops (page perso, ) le 16/05/2008 à 10:48. (lien). Évalué à 8.

pour Kurt Roeckx, auteur de la gaffe.... Il doit se sentir bien seul.

Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'est

Posté par herodiade () le 16/05/2008 à 12:20. (lien). Évalué à 10.

* Le second appel à MD_Update(), celui qui était dès le départ encadré par
un '#ifdef PURIFY' est totalement facultatif. Donc :
1) contrairement à ce qui a été écrit plus haut par iZnogood, un openssl
standard compilé avec -DPURIFY ne pause aucun problème . Et
2) on peut aisément comprendre qu'une lecture rapide/superficielle du code
ou du patch conduise à croire que le premier appel à MD_Update(), dans le
même fichier, puisse être traité de la même manière (ce qui n'est en fait pas le cas).

* Kurt (le développeur Debian à l'origine du patch problématique) a soumis son
patch pour revue sur la liste de diffusion openssl-dev[1], ce qui n'a pas
suscité de mise en gardes (mais l'upstream n'a pas choisi d'intégrer ce
patch, et pour cause). Cette façon d'échanger avec l'upstream présentait
cependant plusieurs graves défauts, comme le signale d'ailleurs Damien Miller
(le développeur principal d'OpenSSH)[1] :
1) openssl-dev est en pratique une liste d'utilisateur d'openssl (ou de
développeurs d'applications utilisant openssl), et pas la liste des
développeurs de la lib openssl (openssl-team), et encore moins le bugtracker.
Seulement la description de la liste sur le site d'openssl ne reflète pas ce
fait.
2) Il n'a pas du tout précisé qu'il était mainteneur du paquet debian et
qu'il comptait y intégrer ce patch et le distribuer à tout les utilisateurs.
Vu que son mail parle seulement de problème avec valgrind (utilisation de la
lib en condition de debug), et sur une m-l pour les devs de programmes
utilisateurs, son messsage a vraissemblablement été interprété comme
"salut, je n'arrive pas à valgrinder mon appli sur mon poste perso parce
qu'elle utilise openssl, est-ce que ce quick hack peut me tirer d'affaire ?"
3) Ce qu'il a envoyé sur la mailing-list n'est pas un patch, mais une
question (ce qui n'aidait pas à deviner ses réelles intentions).
4) S'il s'était donné la peine de googler "valgrind openssl", ou simplement
de chercher dans le bugtracker d'openssl, il aurait vu, des tonnes de fois,
la réponse des devs à ce problème[3].

* Certains (cf. par ex. Sytoka Modon plus haut) semblent avoir mal compris
pourquoi cette fonction peut utiliser de la mémoire non initialisée. Si
openssl fait brailler valgrind, ce n'est pas que leur code est sale. Et non,
openssl ne compte pas sur cette zone de mémoire pour vraiment contenir un
aléas solide et suffisant. La fonction :
"static void ssleay_rand_add(const void *buf, int num, double add)" ,
celle dont les appels à "MD_Update(&m,buf,j);" ont été commentés par Debian,
est une fonction interne d'openssl appellée par la fonction "publique"
(documentée et exposée aux utilisateurs de la lib) :
"int RAND_bytes(unsigned char *buf, int num);".
La page de man de RAND_bytes(3ssl) explique clairement :
"The contents of buf is mixed into the entropy pool before retrieving the
new pseudo-random bytes unless disabled at compile time (see FAQ)."
Bref, c'est un comportement parfaitement documenté, le buffer "buf" (transmis
depuis l'application utilisatrice jusqu'à MD_Update()) sera accédé en
lecture, et pas seulement en écriture.
Si l'utilisateur le souhaite, il peut "pré-remplir" le buffer "buf" avec des
données venant de /dev/random, ou autre, avant d'appeler RAND_bytes(), et ainsi
augmenter à souhait l'entropie du système tout en faisant taire valgrind. Le cas
échéant, openssl lit quand même la zone mémoire "buf" (parce que MD_Update()
ne sait pas si elle a été initialisée de la sorte, et parce que même si elle
ne l'a pas été, elle peut contenir n'importe quoi, ce qui est toujours un
petit poil d'aléas bon à prendre même si non vital). Ensuite, le MD_Update()
mixe le contenu de "buf" avec du vrai aléas obtenu de façon dépendante de la
plateforme (/dev/urandom /dev/arc4random, etc.) : on ne dépend pas du fait
que le contenu, initialisé ou pas, dans "buf" soit réellement aléatoire ou pas.
Mais on dépend du fait que l'appel à MD_Update() soit bien éffectué, sinon
ce mélange de buf et de vrai aléas n'a pas lieu. Ceci explique pourquoi une
solution telle que : "memset(buf, 0, sizeof buf); MD_Update(&m,buf,j);",
qui aurait fait taire valgrind, aurait plutôt diminué la qualité du code
et de l'entropie. Le probleme ici est que le développeur Debian a purement
et simplement enlevé l'appel à MD_Update().

* Debian et Ubuntu distribuent désormais une versions d'openssh patchée pour
rejeter les clefs fragiles, et contenant un nouvel outil (ssh-vulnkeys)
censé aider à trouver les clefs fragiles sur le système. Il sera
malheureusement nécéssaire que les autres distribs (et les *BSD, et Solaris,
etc.) fassent de même *très rapidement*. Et il serait de bon ton de la part de
ces deux distributions responsables d'y aider, et aussi de distribuer l'openssh
patché pour Sarge et Ubuntu 6.06 LTS (arrétons l'hypocrisie et les résolutions
psychorigides : même si ces deux distribs ne sont plus officiellement supportées
depuis peu (un ou deux mois), elles sont encore utilisées).

* Complètement ahurissant et irresponsable : le correctif sécurité Debian a été
commité, publiquement 5 jours avant la publication de l'advisory ![4]
Pourtant, même la doc officielle pour les développeurs Debian rappelle
l'évidence, qu'il ne faut pas faire ça.[5]


### Aussi, pour éviter que ça se reproduise, on peux facilement en déduire que :

* Les mainteneurs de paquets dans les distributions devraient toujours
soumettre leurs patchs à l'upstream, *en n'omettant pas d'indiquer qu'ils
sont maiteneurs du paquet et ce qu'ils comptent faire du patch* (qu'ils
comptent l'intégrer dans le paquet, qu'il ne s'agit pas d'un simple
quick hack sur leur poste perso pour pouvoir mieux débugguer une appli
en cours de développment avec valgrind).

* Comme le rappelle Ben Laurie[6] (dev openssl), un mainteneur de paquet ne
devrait jamais distribuer sa correction d'un problème qu'il ne comprends pas
(une résolution "à tatons") ou dans un segment de code qu'il ne comprends
pas. Surtout si ce patch touche une composant central d'une bibliothèque
vitale pour la sécurité de l'OS et très utilisée.

* Les outils automatiques de fiabilisation (de valgrind à SELinux en passant
par snort ou gcc -fstack-protector) ne peuvent rien pour prévenir ce type de
bourdes ou leurs conséquences. Autrement dit, retenons qu'ils ne remplaceront
jamais la nécessité d'une relecture et validation humaine systématique du code
par un pair "expert". Le bon vieux modèle "audit et relecture systématique par
un ancien" à la façon OpenBSD a du bon (ce qui ne signifie pas que le modèle
"prévention automatisée à la SELinux/Red Hat est moins bon, mais le premier
reste nécessaire). Debian devrait imposer la validation des patchs, au moins
sur les composants critiques.

* Le problème aurait aussi été évité si le développeur Debian avait regardé le
bugtracker d'openssl (où il a déjà été question de son problème) - et je
considère que regarder ce bugtracker est son boulot ; il aurait aussi été
évité si les développeurs openssl suivaient les "vendor patchs" dans les
distros, ou simplement les bugtrackrs des distros. Il y a de grosses marges
de progrès là (et des "meta" bugtrackers pourraient aider).

* Documenter les pièges de ce genre dans la code (un simple commentaire...) ne
mange pas de pain. Même si c'est documenté dans la page de man, le
bugtracker et sur la mailing-list (via goole).


[1] Post de Kurt sur openssl-dev : http://marc.info/?l=openssl-dev&m=114651085826293&w=(...)
[2] Remarque de Damien Miller : http://marc.info/?l=openbsd-misc&m=121088162320794&w(...)
[3] Par exemple ici, en 2003 http://rt.openssl.org/Ticket/Display.html?id=521&user=gu(...)
[4] http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/cryp(...)
[5] http://www.debian.org/doc/developers-reference/ch-pkgs.en.ht(...)
[6] Ben Laurie : http://www.links.org/?p=327

Mesures qui seront prises ?

Posté par Henry-Nicolas Tourneur (Jabber id, page perso, ) le 16/05/2008 à 12:47. (lien). Évalué à 3.

Bonjour,

On peut très souvent lire des commentaires du genre, l'erreur est humaine (ce qui est vrai) leurs réponses ainsi que des explications permettant de détecter les mauvaises clés.

Moi, en tant qu'utilisateur Debian, ce qui m'intéresse c'est de savoir ce que Debian compte faire pour éviter que cela se reproduise. Je pense que vu le seuil critique qu'a atteint cette erreur, la confiance (en tout cas pour moi) envers Debian se trouve au moins en partie ébranlée (dans le genre, on pourrait se dire que si cela arrive avec OpenSSL, pourquoi pas avec GnuPG ou le kernel).

Donc ce que moi j'aimerai savoir (et c'est pour ça que je poste, si quelqu'un a une réponse) c'est ce que Debian compte faire, des restructurations par exemple. On pourrait imaginer crée un tag pour les paquets critiques du système et que les patchs de ces paquets doivent obligatoirement être relu par une autre team (Quality Assurance ?) avant d'être inclut dans la prochaine version stable. Je me doute que cela peut représenter beaucoup de travail et je ne sais pas si c'est réalisable, c'est juste une idée.

J'ai regardé les tags pour OpenSSL, il y a security:cryptography (entre autre), mais ça ne le différencie pas d'un paquet comme kgpg qui est aussi taggé security:cryptography donc il faudrait autre chose.

Enfin bref, moi ce qui m'intéresse le plus c'est de savoir ce que Debian compte faire pour minimiser le risque que cela se reproduise.

Si quelqu'un a des informations là-dessus, ce serait bien d'en parler.

Un des premières conséquences...

Posté par Khâpin (Jabber id, page perso, ) le 16/05/2008 à 15:42. (lien). Évalué à 6.

l'auteur d'xkcd a eu du mal à uploader son dessin du jour
http://xkcd.com/424/
True story: I had to try several times to upload this comic because my ssh key was blacklisted.

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.9985s (dont 0.1195 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !