Journal : Vulnérabilité Debian
Posté par snt () le 13 mai 2008
0
C'est énorme : La version d'openssl packagé par debian génère des clés de chiffrement prévisibles ! Donc non seulement, il faut mettre à jour vos machines, mais en plus il faut regénérér toutes vos clés, ou alors il ne faudra pas pleurer après.Plus d'infos sur :
http://lists.debian.org/debian-security-announce/2008/msg001(...)
> Lire le journal (97 commentaires, moyenne: 2,8).
Vous avez demandé le commentaire #930483.
Run by 
Cette page a été générée par Templeet en 0.1136s (dont 0.009 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Debian et dérivées
Ça ne concerne pas que Debian, mais aussi les distributions dérivées de Debian (Ubuntu, MEPIS, etc).
"Heureusement", c'est spécifique Debian.
Mais notons bien que Debian n'a pas proposé le patch en upstream...
En upstream on lui aurait : "- malheureux, ne fais pas ça !"
[^]Re: Debian et dérivées
Pour ubuntu, ça concerne les versions 7.04, 7.10 et 8.04.
http://www.ubuntu.com/usn/usn-612-1
http://www.ubuntu.com/usn/usn-612-2
[^]Re: Debian et dérivées
#apt-get dist-upgrade
...
ATTENTION : les paquets suivants n'ont pas été authentifiés.
... libssl-dev libssl0.9.8 openssh-client openssh-server openssl ...
Ils les ont signés avec le nouveau openssl? (loup qui se mord la queue toussa?)
[^]Re: Debian et dérivées
Ça n'affecte pas les clées générées avec gpg.
[^]Re: Debian et dérivées
ok, je savais pas.
Mais c'est quand même bizarre de pas signer des paquets aussi cruciaux.
[^]Re: Debian et dérivées
> Mais c'est quand même bizarre de pas signer des paquets aussi cruciaux.
C'est clair.
C'est simple, chez moi je n'installe jamais un paquet non-signé. Ou alors après une vérification, ou pour une bécane de test, etc.
Si c'est pour ma bécane ou une bécane en production, alors ça doit être signé.
Bref => n'installes pas.
[^]Re: Debian et dérivées
t'inquiètes pas, j'attends la version signée. Je n'installe jamais de paquets pas signés.
IMHO, la conf par défaut de apt-get devrait forcer à passer une option en ligne de commande (genre --oui-je-suis-sur-j-assume ) avant de proposer de contourner la signature. Là c'est trop facile d'accepter, et ceux qui n'ont jamais entendu parler d'openssl (la cible ubuntu) penseront à une question "are you sure?" de plus, et accepteront. D'ailleurs la mise à jour est noyée au milieu de trucs classiques (bash cpp libgcj-bc libgphoto2-2... ).
[^]Re: Debian et dérivées
C'est simple, chez moi je n'installe jamais un paquet non-signé.
Et dire que tu me traitais de parano parce que j'utilise https quand c'est disponible... hôpital, charité, tout ça... ;)
(oui oui, c'est hors-sujet, -1)
[^]Re: Debian et dérivées
C'est ma bécane !
Tu vois la nuance ?
L'installation d'un paquet rpm peux exécuter n'importe quelque script ou programme sous root.
[^]Re: Debian et dérivées
Tu vois la nuance ?
Non. Mais je ne voulais pas relancer le débat, juste te taquiner un peu.
[^]Re: Debian et dérivées
Là il est clair que c'est une énorme bourde des mainteneurs du paquet OpenSSL de Debian.
Plusieurs personnes parlent de retirer le paquet des mains du ou des coupables...
[^]Re: Debian et dérivées
On va peut-être éviter les expéditions punitives ?
Il a certainement très bien retenu la leçon maintenant.
Par contre, faudrait qu'Ubuntu qui fait des distributions "entreprise" audite mieux ce qui est fait pour les paquets critiques. Ça fait depuis 1 an que ça traine chez Ubuntu.
Espérons qu'aucune bécane ne va être crackée, sinon Ubuntu va se prendre une volée de bois vert.
[^]Re: Debian et dérivées
Tu n'en manques pas une pour critiquer Ubuntu, hein.
[^]Re: Debian et dérivées
> En upstream on lui aurait : "- malheureux, ne fais pas ça !"
En fait :
http://www.links.org/?p=327
we (the OpenSSL Team) would have fallen about laughing, and once we had got our breath back, told them what a terrible idea this was.
[^]Re: Debian et dérivées
et si on lit les commentaires , on 'est renvoyé vers :
http://marc.info/?t=114651088900003&r=1&w=2
où on voit que
1°) le dvp debian a demandé upstream
2°) la team openssl a dis "Si c'est pour le debug, je suis d'avis qu'on puisse le virer".
Comme quoi, rien n'est simple, et, une chose est sur, les gens qui se moquent après ne valent guère.
Comme disait dans un manga "J'ai vu personne me faire chier pendant, alors venait pas pas me faire chier après".
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Debian et dérivées
> 2°) la team openssl a dis "Si c'est pour le debug, je suis d'avis qu'on puisse le virer".
Ben oui. Mais Debian ne l'a pas fait que pour la version debug.
Le patch qui corrige :
http://svn.debian.org/wsvn/pkg-openssl/openssl/trunk/crypto/(...)
Où tu vois le "#ifdef ..." ?
[^]Re: Debian et dérivées
pas dis que debian était au dessus de tout reproche, mais quand je vois quelqu'un dire "si ils étaient venu nous dire ca on lui aurai ri a la gueule" (alors que c'était loin d'etre trivial comme probleme), je trouve ca plutot naze...
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Debian et dérivées
> mais quand je vois quelqu'un dire "si ils étaient venu nous dire ca on lui aurai ri a la gueule"
Mais ce n'est pas grave !
C'est le rire, ce n'est pas controlable.
Ils auraient bien rigolé, puis lui aurait dit de ne pas faire cette connerie.
Mais clairement ils préfèrent être informé (et si en plus c'est l'occasion de se marrer :-)).
Avec cette faille diffusé à des millions d'exemplaires, c'est beaucoup moins drole.
[^]Re: Debian et dérivées
ben qu'un gars qui n'a pas fait la moindre recherche (vu que le probleme a été évoqué sur la liste de diffusion d'openssl), s'impose comme "expert" sur un sujet déja traité, alors que les "experts" a ce moment, avait dit que ce n'était pas forcément critique.(sous certaines conditions je suis d'accord).
Que cette personne donne des leçon, alors que les problèmes avaient déja été soulevé par le dvp debian en personne avant même de lancer le patch.
Bref, en gros que la personne du billet traite tout le monde de haut sans prendre la peine de se renseigner un minimum, et essaie de se faire mousser comme ça, pour moi ca reste bien naze.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Debian et dérivées
Merde ! On a cloné béranger sans rien me dire ?
~~~> [ ]
[^]Re: Debian et dérivées
pas dis que debian était au dessus de tout reproche, mais quand je vois quelqu'un dire "si ils étaient venu nous dire ca on lui aurai ri a la gueule" (alors que c'était loin d'etre trivial comme probleme), je trouve ca plutot naze...
Attention il y a deux choses :
- Premièrement les mainteneurs Debian ont demandés si c'était normal que le pool d'entropie ne soit pas initialisé à la création. Ce à quoi l'équipe OpenSSL a répondu que pour le debug ils pouvaient initialiser le pool.
- Deuxièmement les mainteneurs Debian ont ont retirés toute possibilité d'ajouter de l'entropie à ce pool (c'est à dire qu'il ne se sont pas contenter de l'initialiser, maisqu'ils l'ont vérouillé à une valeur connue), enlevant ainsi 99% de l'aléatoire dans la génération de clefs.
Autant le premièrement n'est pas trivial, autant le deuxièmement montre qu'ils sont complètement à coté de la plaque.
Kha
root est un privilège, pas un droit !
[^]Re: Debian et dérivées
- Premièrement les mainteneurs Debian ont demandés si c'était normal que le pool d'entropie ne soit pas initialisé à la création. Ce à quoi l'équipe OpenSSL a répondu que pour le debug ils pouvaient initialiser le pool.
- Deuxièmement les mainteneurs Debian ont ont retirés toute possibilité d'ajouter de l'entropie à ce pool (c'est à dire qu'il ne se sont pas contenter de l'initialiser, maisqu'ils l'ont vérouillé à une valeur connue), enlevant ainsi 99% de l'aléatoire dans la génération de clefs.
Je ne suis pas d'accord avec ton interprétation de la réponse et du patch. Relis bien tout le thread en question : le mainteneur Debian quote les deux lignes qu'il souhaite supprimer, et il est même très prudent : « But I have no idea what effect this
really has on the RNG ». Un des mecs de l'équipe de développement d'OpenSSL répond : « If it helps with debugging, I'm in favor of removing them. ». Il répond à la demande de suppression des deux lignes (ce qui deviendra exactement le patch), pas à la question en rapport avec la non initialisation du buffer. Donc à l'erreur consistant à supprimer toute entropie au pool. Il n'a pas vu l'erreur lui non plus !
Pour moi, le mainteneur Debian n'a rien à se reprocher quant à son comportement. Il a fait une énorme boulette, mais il l'a faite dans les règles de l'art : avec des doutes, et en demandant upstream. Si upstream dit que c'est bon, eh bien voilà, les torts sont largement partagés.
[^]Re: Debian et dérivées
Sauf erreur de ma part (j'ai pas de quoi aller ouvrir les vieux .deb et vérifier par moi même) le problème ne vient pas tant du patch que du fait que tous les packages debian ont étés compilé avec l'option purify.
Kha
root est un privilège, pas un droit !
[^]Re: Debian et dérivées
Non, le problème vient bien de la suppression des deux lignes MD_Update. Je t'ai mis le diff de etch "d'origine" ici si tu veux voir, il n'y a aucune activation particulière de purify.
http://zarb.org/~gc/t/openssl_0.9.8c-4etch1.diff.gz
[^]Re: Debian et dérivées
La pratique d'avoir une branche Debian est très très discutable.
Chez Fedora ce sont les patchs individuels qui sont stockés. Il est alors facile de savoir qui fait quoi et pourquoi. Il est plus facile d'envoyer des patchs en upstream, de faire auditer ses patchs, etc.
Cette pratique de Debian a aussi agacé Mozilla...
J'espère que tous les paquets Debian ne sont pas géré comme ça. Parce qu'en gros Debian fait un fork.
[^]Re: Debian et dérivées
La pratique d'avoir une branche Debian est très très discutable.
Oui et non, parfois c'est même à peu près obligatoire. par exemple pour FFMpeg, vu le nombre de logiciels qui utilisent des versions légèrement différentes de cette lib c'est très vite la pagaille. Le plus simple est d'avoir une seule lib pour toutes les applis quitte à modifier les applis pour qu'elles fonctionnent avec cette lib là.
En plus en cas de faille sur une dépendance c'est nettement plus simple de répercuter la correction juste sur la lib que sur tous les logiciels un par un quand ils inclus chacun leurs lib.
Kha
root est un privilège, pas un droit !
[^]Re: Debian et dérivées
Comprend pas.
[^]Re: Debian et dérivées
C'est pas exactement "Si c'est pour le debug, je suis d'avis qu'on puisse le virer" qui a ete dit.:
http://marc.info/?l=openssl-dev&m=114652287210110&w=(...)
"If it helps with debugging, I'm in favor of removing them. "
Dans la phrase en anglais, je comprends qu'il est favorable a la proposition de l'enlever definitivement si ca aide pour le debuggage sans parler de condition a la #ifdef DEBUG. Du moins c'est comme ca que je le comprends.
[^]Re: Debian et dérivées
Oui, complètement. D'autant plus que le contexte est le problème à debugger des programmes utilisant openssl avec valgrind à cause de cela. Donc il répond bien que pour faciliter le debug "des applications utilisant openssl", ce patch ne devrait pas faire de mal. Le tort est vraiment partagé.
[^]Re: Debian et dérivées
Plus loin dans les commentaires on peut lire :
It seems that the Debian maintainer did, indeed, mention his plan on openssl-dev. Openssl-dev is a list for people developing OpenSSL based software, not a list for discussing the development of OpenSSL itself. I don’t have the bandwidth to read it myself. If you want to communicate with the OpenSSL developers you need to use openssl-team@openssl.org. At no time, as people have suggested, was a patch offered to OpenSSL, and the discussion on openssl-dev was misleading.
Donc le dvp debian ne s'est visiblement pas adressé à la bonne personne !
[^]Re: Debian et dérivées
et si on regarde openssl-dev on voit des questions comme
http://groups.google.com/group/mailing.openssl.dev/browse_th(...)
ou il est question de
"When doing BIO_pop(), OpenSSL increases the reference counter of the
remaining BIO chain instead of decreasing it. This leads to memory and
fd leaks if you use BIO_pop(). Here is a patch: "
Visiblement c'est loin d'etre le seul a prendre openssl-dev pour la liste de developpement.
Mais le plus beau c'est pas ca; c'est que si on se renseigne UN MINIMUM : on trouve cette page :
http://www.openssl.org/support/
ou il y a marqué :
openssl-dev open subscribers Discussions on development of the OpenSSL library. Not for application development questions!
Alors, a ton avis, qui a raison, le site web d'open ssl, ou un commentaire sur un blog qui essaie de se faire mousser ?
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Debian et dérivées
Le site bien sûr. Mais bloggeur fait partit de la core team d'openssl, si il ne sait pas ou se font les remontés d'info c'est quand même grave !!
[^]Re: Debian et dérivées
ben en même temps si ils mettent pas a jour le site, et attendent un truc sur une mailing list, alors que
1°) la mailing list (openssl-team) en question n'est pas mentionné sur le site, donc peu de "nouvelles" personnes devraient y accéder
2°) la mailing list des applications (openssl-dev) soit considéré par ce dvpeur comme exactement contraire à sa défintion sur le site
3°) qu'il existe déja une mailing list pour les applications, mais que bizarrement ils auraient changé
et que ces 3 fois, il n'a strictement rien remarqué et explique le contraire du site web, faut qu'il arrête la sécurité.
Quand on voit un truc comme "probleme dans la librairie openssl" sur openssl-dev (et y'a pas franchement qu'un message comme ça) et qu'on se dise pas "bizarre que tout le monde la prenne pour celle de dvp quand meme", pour qu'il arrive a trouver un quelconque bug, je lui souhaite bonne chance.
Allez, google test :
"openssl-team@openssl.org" 63 réponses
"openssl-dev@openssl.org" 19700 réponses.
pour un projet aussi connu que openssl, pour avoir que 63 réponses sur google dans mailing list de developemment, j'émet quand même certains doutes.
Bref il me fait furieusement penser à theo : "C'est forcément de la faute des autres.
Le problème ne peut pas être chez nous/moi".
Tu remarquera qu'il a pas relevé que le dvp a dis "j'avais bien vu le probleme" mais "il a bien dis ce qu'il voulait faire."
Il a pas relevé que des gens de la team openssl lui disait "ca semble ok", mais "il c'est gouré de mailing list".
etc...
Et comble de l'excuse "je n'ai pas la bande passante nécessaire pour lire openssl-dev" ...
(sachant qu'il y a des interfaces graphiques avec recherche pour cette liste, ca peut difficilement être une excuse valable, d'autant plus qu'il peut recharger son blog qui prend bien plus en bp ...)
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Debian et dérivées
> les gens qui se moquent après ne valent guère.
Je n'ai pas reproché à Debian de faire des patchs, mais de ne pas les remonter upstream.
Sinon rigolons un peu :
http://www.br0kenhalo.com/?p=49
int getRandomNumber() {
return 4 ;
}
[^]Re: Debian et dérivées
calme toi isnotgood, ce n'est pas a toi que je reprochait de se moquer, mais l'auteur du billet de "http://www.links.org/?p=327"
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Debian et dérivées
merde j'avais pas vu la blague.
Elle est plus drole avec les commentaires je trouve :)
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Debian et dérivées
Rendons a Cesar ce qui lui appartient :
http://xkcd.com/221/
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
[^]Re: Debian et dérivées
«En upstream on lui aurait : "- malheureux, ne fais pas ça !"»
Non, sérieusement, tu veux dire que chez OpenBSD ils utilsent un langage aussi chatié? Rhaa tout fout le camp, je vous le dis ma bonne dame, tout fout le camp...
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: Debian et dérivées
les clefs qui ont été genéré par ce programme et donc pas toutes les debians
certaines ont des clef généré par une version plus ancienne
pour protester contre la dadvsi , je n'achete plus de produit soumis au droit d'auteur ou voisins