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(...)
Journal Vulnérabilité Debian
13
mai
2008
# Debian et dérivées
Posté par IsNotGood . Évalué à 4.
"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
Posté par Ozz . Évalué à 2.
http://www.ubuntu.com/usn/usn-612-1
http://www.ubuntu.com/usn/usn-612-2
[^] # Re: Debian et dérivées
Posté par riba . Évalué à 3.
...
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
Posté par IsNotGood . Évalué à 5.
[^] # Re: Debian et dérivées
Posté par riba . Évalué à 1.
Mais c'est quand même bizarre de pas signer des paquets aussi cruciaux.
[^] # Re: Debian et dérivées
Posté par IsNotGood . Évalué à 4.
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
Posté par riba . Évalué à 3.
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
Posté par Yusei (Mastodon) . Évalué à 10.
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
Posté par IsNotGood . Évalué à 1.
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
Posté par Yusei (Mastodon) . Évalué à 8.
Non. Mais je ne voulais pas relancer le débat, juste te taquiner un peu.
[^] # Re: Debian et dérivées
Posté par Pinaraf . Évalué à 1.
Plusieurs personnes parlent de retirer le paquet des mains du ou des coupables...
[^] # Re: Debian et dérivées
Posté par IsNotGood . Évalué à 6.
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
Posté par ohmer . Évalué à 0.
[^] # Re: Debian et dérivées
Posté par IsNotGood . Évalué à 2.
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
Posté par briaeros007 . Évalué à 6.
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".
[^] # Re: Debian et dérivées
Posté par IsNotGood . Évalué à 2.
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
Posté par briaeros007 . Évalué à 7.
[^] # Re: Debian et dérivées
Posté par IsNotGood . Évalué à 2.
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
Posté par briaeros007 . Évalué à 9.
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.
[^] # Re: Debian et dérivées
Posté par liberforce (site web personnel) . Évalué à 0.
~~~> [ ]
[^] # Re: Debian et dérivées
Posté par Jerome Herman . Évalué à 5.
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.
[^] # Re: Debian et dérivées
Posté par gc (site web personnel) . Évalué à 10.
- 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
Posté par Jerome Herman . Évalué à 1.
[^] # Re: Debian et dérivées
Posté par gc (site web personnel) . Évalué à 3.
http://zarb.org/~gc/t/openssl_0.9.8c-4etch1.diff.gz
[^] # Re: Debian et dérivées
Posté par IsNotGood . Évalué à 4.
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
Posté par Jerome Herman . Évalué à 3.
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.
[^] # Re: Debian et dérivées
Posté par IsNotGood . Évalué à 0.
[^] # Re: Debian et dérivées
Posté par Alban Crequy (site web personnel) . Évalué à 7.
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
Posté par gc (site web personnel) . Évalué à 4.
[^] # Re: Debian et dérivées
Posté par atarakt . Évalué à 1.
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
Posté par briaeros007 . Évalué à 10.
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 ?
[^] # Re: Debian et dérivées
Posté par atarakt . Évalué à 2.
[^] # Re: Debian et dérivées
Posté par briaeros007 . Évalué à 2.
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 ...)
[^] # Re: Debian et dérivées
Posté par IsNotGood . Évalué à 4.
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
Posté par briaeros007 . Évalué à 0.
[^] # Re: Debian et dérivées
Posté par briaeros007 . Évalué à 4.
Elle est plus drole avec les commentaires je trouve :)
[^] # Re: Debian et dérivées
Posté par imalip . Évalué à 10.
http://xkcd.com/221/
[^] # Re: Debian et dérivées
Posté par psychoslave__ (site web personnel) . Évalué à 4.
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...
[^] # Re: Debian et dérivées
Posté par modr123 . Évalué à 2.
certaines ont des clef généré par une version plus ancienne
# Les certifs SSL achetés une fortune...
Posté par Sufflope (site web personnel) . Évalué à 8.
# L'image du logiciel libre en prend un coup !
Posté par ☂ Tramo . Évalué à -7.
[^] # Re: L'image du logiciel libre en prend un coup !
Posté par M . Évalué à 1.
[^] # Re: L'image du logiciel libre en prend un coup !
Posté par ß ß . Évalué à 4.
Dommage qu'on ne soit pas vendredi. Ça aurait pu fonctionner.
# Pas seulement les cles generees sur Debian
Posté par Alban Crequy (site web personnel) . Évalué à 4.
Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation.
(Dans ce cas là le "bug" ne permet pas de trouver la clé mais de se logger sans avoir besoin de la clé initiale.)
Pas de chance pour moi, ma clé a été généré sur AIX mais je l'utilise couramment sur Debian :-(
[^] # Re: Pas seulement les cles generees sur Debian
Posté par JereMe . Évalué à 2.
Dans ce cas là le "bug" ne permet pas de trouver la clé mais de se logger sans avoir besoin de la clé initiale.
Je trouve le passage que tu cites très très flou et des précisions sont bienvenues mais je ne mettrais pas ma main a coupé que ce bug ne permette pas de trouver la clé privé (à partir de la clé publique + de signatures faibles faites par la machine ayant le bug et permettant de remonter à la clé privé).
Si quelqu'un peut m'éclairer ...
[^] # Re: Pas seulement les cles generees sur Debian
Posté par khivapia . Évalué à 5.
Plus loin que ça, si pour deux signatures, les deux valeurs du paramètre aléatoire sont identiques, alors on peut retrouver la clef secrète.
[^] # Re: Pas seulement les cles generees sur Debian
Posté par JereMe . Évalué à 2.
# Wishlist
Posté par Aefron . Évalué à 2.
... bon, le problème semble plutôt être que ça créerait trop de dépendances, et que ça pourrait gêner les petits systèmes... m'enfin, à la limite, ce serait bien d'avoir un autre .deb en plus, ie openssl-opensc...
Mais a priori, les clés privées n'étant pas censées quitter un token pour êtres exposées au système, et le couple clés privée/publique y étant généré, le problème ne se poserait pas, en ce cas, pour openssh, qui est, pour ce qui me concerne, le plus pénible...
... enfin, si probablement : pour ce qui est de la clé chiffrant la communication, une fois la transaction établie : mais ça ne supposerait que d'attendre la mise à jour d'openssl, et pas de régénérer toutes ses clés.
Voilà que la paranoia recommence à me démanger...Ce serait bien, quand même, une petite smartcard...
[^] # Re: Wishlist
Posté par ribwund . Évalué à 3.
[^] # Re: Wishlist
Posté par Aefron . Évalué à 2.
Je ne dis pas que c'eût été la solution à tout... je me demande juste si ça n'aurait pas limité la casse d'avoir la possibilité d'utiliser du token dans le cas d'openssh, avec de la RSA dedans... le token devrait s'occuper tout seul de générer les clés si on lui demande, et sans devoir demander à openssl de les générer, non ?
Et, je peux me tromper, mais comme il ne semble pas que RSA ait besoin d'une valeur aléatoire via openssl pour athentifier/signer, le problème devrait se limiter à celui de la génération des clés, justement confiée au token, contrairement aux clés DSA dont la simple utilisation avec la version incriminée d'openssl suffit pour être dans la panade...
Lorsqu'il m'est arrivé de faire du lego tortueux pour ne pas exposer mes clés SSH (en les mettant sur une clé USB dont je me sers vaguement comme d'un token du pauvre... avant tout pour que n'importe qui ne puisse pas avoir accès à des clés privées que je laisserais traîner dans mon /home, plus qu'autre chose), on m'a souvent suggéré d'utiliser un token (donc, pour des raisons différentes de celles qui me turlupinent dans ce bug)... mais ça a quand même l'air assez peu répandu et cher (d'autant que la plupart des offres que j'ai vues demandaient à commander des quantités conséquentes... orienté entreprise probablement)...
D'ailleurs, quand j'ai demandé des précisions sur le sujet à ceux qui m'en parlaient : silence radio... je n'ai jamais trop vu de retours sur ce genre de choses ; j'ai beau être passionné par ce qu'on peut faire avec un réseau et les OS libres, je reste un profane autoditacte, non-professionnel, en la matière... je ne crache pas non plus sur des retours argumentés sur ces tokens : sont-ils vraiment si surfaits que ça, pour qu'ils aient l'air si peu répandus et que leur gestion soit si peu implémentée dans des choses comme openssh, notamment, pour la distro dont il est question dans ce journal (et que j'utilise au quotidien), par Debian ? Bref, pourquoi, monde cruel !?
[^] # Re: Wishlist
Posté par Anonyme . Évalué à 1.
[^] # Re: Wishlist
Posté par ribwund . Évalué à 2.
[^] # Re: Wishlist
Posté par wismerhill . Évalué à 2.
[^] # Re: Wishlist
Posté par briaeros007 . Évalué à 1.
# tests
Posté par M . Évalué à 2.
On pourrait imaginer une suite de test qui testerait l'aléatoire des clefs, a la sorti du générateur aléatoire avoir un filtre/test de l'aléatoire (un peu comme ce que fait le démon de rng-tools pour les générateurs aléatoire hardware pas forcement géniaux).
[^] # Re: tests
Posté par Larry Cow . Évalué à 3.
Le débat viendra dans un second temps, je pense. L'urgence, c'est de communiquer pour éviter le pire.
On pourrait imaginer une suite de test qui testerait l'aléatoire des clefs, a la sorti du générateur aléatoire avoir un filtre/test de l'aléatoire (un peu comme ce que fait le démon de rng-tools pour les générateurs aléatoire hardware pas forcement géniaux).
C'est possible ça? Pourquoi le script perl fourni par debian pour vérifier les clés (dowkd.pl) ne l'utilise pas?
[^] # Re: tests
Posté par Anonyme . Évalué à 1.
C'est trop tard pour les clefs pas assez aleatoires, c'est deja fait. La prochaine fois ca sera un autre truc :)
# Ubuntu 8.04 : Attention
Posté par André Rodier . Évalué à 3.
- Que l'access ssh avec mot de passe est désactivé (Options PasswordAuthentication no et UsePAM no)
Si vous faites un apt-dist-upgrade, vos clefs sont apparament désactivées, et vous ne pourez plus vous logger.
Pas très intelligent comme mise à jour.
[^] # Re: Ubuntu 8.04 : Attention
Posté par gc (site web personnel) . Évalué à 1.
[^] # Re: Ubuntu 8.04 : Attention
Posté par André Rodier . Évalué à 4.
Si ssh est le seul access disponible à son serveur, ça veut dire retour d'urgence au datacenter.
[^] # Re: Ubuntu 8.04 : Attention
Posté par Larry Cow . Évalué à 3.
Il risque d'y avoir des embouteillages, au datacenter :)
[^] # Re: Ubuntu 8.04 : Attention
Posté par Larry Cow . Évalué à 5.
[^] # Re: Ubuntu 8.04 : Attention
Posté par Zenitram (site web personnel) . Évalué à 6.
Euh... Perso j'ai un accès par la console de mon hébergeur, reboot sur noyau réseau avec accès aux disques, réparation du probleme par accès SSH du noyau réseau, reboot.
C'est un peu "chaud" de n'avoir que SSH de ta machine, que le noyau de ta machine pour accéder à la machine... Il y a des warriors ici :)
[^] # Re: Ubuntu 8.04 : Attention
Posté par André Rodier . Évalué à 2.
[^] # Re: Ubuntu 8.04 : Attention
Posté par wismerhill . Évalué à 2.
[^] # Re: Ubuntu 8.04 : Attention
Posté par Zenitram (site web personnel) . Évalué à 2.
De quoi tu parles?
D'avoir un noyau réseau de secours? C'est payant chez toi? Mais quitte ton hébergeur!
Perso, j'ai 1 serveur chez Dedibox à 30€/mois et j'ai ce service, j'ai 1 serveur Kimsufi à 20€/mois aussi et j'ai ce service aussi (il me semble, pas testé encore par contre).
Si tu n'as pas les moyens de mettre le prix d'un serveur dédié, ben tu n'as pas de problème SSH...
Ou alors j'ai rien compris.
[^] # Re: Ubuntu 8.04 : Attention
Posté par wismerhill . Évalué à 2.
[^] # Re: Ubuntu 8.04 : Attention
Posté par Boa Treize (site web personnel) . Évalué à 1.
[^] # Re: Ubuntu 8.04 : Attention
Posté par wismerhill . Évalué à 2.
[^] # Re: Ubuntu 8.04 : Attention
Posté par BAud (site web personnel) . Évalué à 3.
- le déplacement sur place
- intervention sur site d'une personne
- l'indisponibilité (temps déplacement + intervention)
À la fin, ce n'est pas forcément des économies de bouts de chandelle qui valent le coup ni le coût :/
[^] # Re: Ubuntu 8.04 : Attention
Posté par wismerhill . Évalué à 2.
Mais moi je suis développeur (et accessoirement administrateur de serveurs par la force des choses (PME bis)) et on ne me consulte pas pour les évaluations de budget (au-delà de simplement me demander combien de temps prendrait tel développement).
# Pour info
Posté par ß ß . Évalué à 10.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332498
Ce n'est pas défendre les debian maintainers (si un peu quand même), étant moi même utilisateur de Debian à titre particulier et professionnel. Toutes les machines que j'utilise sont donc sous debian (excepté les quelques redhats (pour les certifs) et sun (raisons historiques) et un hpux (plus utilisé)).
Donc je me trouve bien embêté pour les certificats que je génère en moyenne hebdomadairement pour le parc de machines et les utilisateurs dont j'ai la charge. À titre personnel, ouf, mes clés ssh et certificats sont suffisamment anciens.
Maintenant on peut avoir deux attitudes :
* Jeter le bébé avec l'eau du bain, adopter une attitude à la OpenBSD/De Raadt "tous des cons ils ne pensent pas comme nous".
* Tenter de voir ce qui n'a pas fonctionné dans la chaîne et tenter de l'améliorer, histoire que ça n'arrive plus (le moins souvent possible).
Cela fait un certain temps que je me suis fait la réflexion que le logiciel libre est une chaine dont les maillons les plus faibles sont :
* La compétence des divers acteurs.
* La confiance que l'on peut accorder à ces différents acteurs.
Je comptais faire un journal là dessus pour partager cette réflexion avec des personnes qui pourront peut être m'apporter des éclairages nouveaux et d'autre points de vue sur ma façon de voir les choses. Je vais me contenter d'un post ici (à moins qu'on plébiscite ce post et que la foule en délire me demande genoux à terre d'en faire un journal, auquel cas, je serais magnanime et accèderai à un telle requête).
Le mythe veut que le logiciel libre prévienne contre les codes malintentionnés (spywares ou pas). C'est certainement vrai pour les logiciels les plus populaires. Cependant, pour les logiciels plus confidentiels, trouvés sur une page obscure sur le net, je serais moins catégorique.
Pour peu que le code soit assez conséquent, je doute que le mainteneur prenne le temps de lire tout le code avant de packager le soft.
Et encore là on a un référent. Si le logiciel n'est pas packagé, il faut le compiler soi même. Autant je peut concevoir qu'une personne prenne le temps de relire ce qu'il package. Autant une personne quia un besoin (potentiellement urgent) va, selon moi, compiler le logiciel et l'utiliser le plus vite possible pour répondre à son besoin.
Les limites d'un tel système sont que le logiciel doit être innovant/performant pour attirer des mainteneurs.
Ou alors il faut qu'il package lui même son logiciel. Mais pour ça, il faut montrer patte blanche auprès de la distrib. Ce qui n'est pas facile, mais une proposition d'aide n'est jamais refusée, car, malheureusement, ce n'est pas du luxe.
Donc les logiciels libres sont sûr si :
* Le développeur est clean et compétant (ou que le mainteneur regarde ce que fait le développeur).
* Le mainteneur est clean également.
Et
* Tous les miroirs proposant une iso de la distrib sont proposés par des personnes qui ne sont pas malintentionnées.
* Tous ces miroirs sont sécure (et n'ont pas été rootés).
Aussi quelque chose qui est amusant. De nombreux espaces de téléchargement proposent des logiciels, et, pour vérifier que l'archive a bien été téléchargée, un md5sum ou un sha1sum. Pourquoi pas. Parfois on trouve également une signature (un .asc en général), histoire d'être sûr de la provenance de l'archive. Mais bon si le miroir est corrompu tu as beau avoir 15 signatures, ça ne te dis pas que le source signé est bien celui que tu cherches. À moins de connaitre la personne qui développe le soft, d'être sûr que c'est toujours lui qui signe les releases et d'avoir sa clé dans ta chaine de confiance.
Après cette (trop) longue disgression (toutes mes excuses, je n'ai pas réussi à condenser plus), revenons en à notre exemple Debian/OpenSSL.
Dans ce cas, ce n'est pas la chaine de confiance qui a été brisée, mais la chaine de compétence. Il ne suffit de pas grande chose. Une personne dans une team (dev ou mainteneur) peut à elle seule compromettre un paquet. C'est peut être différent pour openssl qui est une pierre angulaire de la sécurité, mais dans les devs que j'ai suivit, officiellement, toutes les modifications étaient validés par au moins un autre membre de l'équipe (normalement deux).
Or avec le temps et l'habitude, lorsque les patchs venaient d'une personne en particulier, qui est connue pour faire du code propre et bien maitriser son sujet, les codes étaient regardés de plus en plus vite, plus au niveau de l'indentation et des commentaires que l'algorithme autour du patch (comprendre le patch en profondeur et le code qui appelle la fonction modifiée et comment ça peut l'impacter). Or notre dev compétant s'est retrouvé limite sur une sous partie (infime) du projet qu'il maitrisait super bien (euphémisme). Ça a toujours passé jusqu'au jour où ça ne passait plus. Heureusement dans ce cas, pas trop de casse.
Je déborde beaucoup bien sûr. C'était juste pour faire partager mes réflexions. Dans notre cas, il aurait simplement fallu une meilleure communication entre la team de dev et la team de mainteneurs.
Peut être faut-il rapprocher un peu plus les team de mainteneurs des teams de devs . (ce qui semble-t-il a été tenté par les devs de debian, mais sur la mauvaise mailing list).
Pour une erreur mise en lumière, combien passeront inaperçues ?
[^] # Re: Pour info
Posté par Larry Cow . Évalué à 3.
Si je ne m'abuse, l'idée c'est que le .asc te sert à vérifier que le source a bien été signé par la clé privée du mainteneur, clé qui n'est pas disponible sur le site (manquerait plus qu'çà). Ou alors je nourris des illusions cruelles sur la nature des .asc, mais bon...
[^] # Re: Pour info
Posté par ß ß . Évalué à 2.
À moins de connaitre la personne qui développe le soft, d'être sûr que c'est toujours lui qui signe les releases et d'avoir sa clé dans ta chaine de confiance.Je n'ai jamais dit qu'il était facile de casser ou falsifier une signature. J'ai juste dit qu'il était facile de faire une signature différente.
Prenons un exemple, ce sera plus clair.
Si demain je me rends sur cairographics et je télécharge la dernière release de cairo. Je peux très bien patcher le code et signer mon nouveau paquet avec ma clé à moi. Ensuite si je mets ça à disposition sur un miroir (car c'était de ça qu'il s'agissait dans mon propos), alors qui pourra dire que le paquet n'est pas sûr ? Surtout que ma clé est dans un ring de confiance très important vu que j'ai rencontré plein de dev internationaux avec beaucoup de contacts.
Alors ok, ce n'est pas suffisant car il suffit de savoir que Carl Worth est la personne qui signe les paquets sur cairographics. Mais combien de personnes le savent ? Carl Worth n'est pas si connu que ça. Et quand bien même beaucoup de monde le saurait, faut-il connaitre tous les développeurs susceptible de signer les paquets de tous les logiciels qu'on package ?
Peut être, mais ça fait beaucoup de boulot.
Pour le commentaire plus bas :
C'est certain, le logiciel libre ne garantit pas une «chaîne» parfaite de production. Elle fournie juste AMHA une des meilleurs chaînes possible.Nous somme bien d'accord.
[^] # Re: Pour info
Posté par IsNotGood . Évalué à 2.
> * Jeter le bébé avec l'eau du bain
Non. Une connerie a été faite. Faut arrêter de chercher des excuses.
Mais ça arrive ! C'est comme ça, ça arrive. Personne n'est à l'abris.
[^] # Re: Pour info
Posté par Larry Cow . Évalué à 3.
(désolé, c'est tout à fait infondé, mais c'était trop tentant)
[^] # Re: Pour info
Posté par IsNotGood . Évalué à 1.
Si ils peuvent le faire.
Mais j'ai la faiblesse de croire que c'est moins probable :-)
[^] # Le logiciel libre ne garantit pas une «chaîne» parfaite
Posté par psychoslave__ (site web personnel) . Évalué à 4.
# détails techniques et exploits
Posté par Krunch (site web personnel) . Évalué à 1.
Donc apparemment ça viendrait du fait que le mainteneur qui voulait faire taire Valgrind a « corrigé anticipativement » un peu trop large. « Oh tiens, ça ressemble à la ligne qui génère un warning, on va la supprimer aussi. »
Et pour les kiddies, il y a de quoi s'amuser par là (entre autres) : http://metasploit.com/users/hdm/tools/debian-openssl/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: détails techniques et exploits
Posté par pasBill pasGates . Évalué à 3.
Si ca se trouve le gars est un developpeur cale, mais quand tu ne maitrise pas le code sur lequel tu bosses(techno peu connue / complexe / grosse base de code...) t'as beau etre cale les catastrophes sont possibles et probables.
[^] # Re: détails techniques et exploits
Posté par Anonyme . Évalué à 4.
Si on regarde les alertes de sécurité, 99% proviennent de bugs dans les logiciels upstream, c'est par par ce qu'il y a un problème une fois avec un patch ajouté par le mainteneur du package qu'il faut en conclure n'importe quoi.
[^] # Re: détails techniques et exploits
Posté par briaeros007 . Évalué à 1.
Comme quoi ...
Des fois , meme si tu es calé, tu connais le code, tu as las doc, des catastrophes sont possibles et probables.
[^] # Re: détails techniques et exploits
Posté par IsNotGood . Évalué à 0.
Arrêtes de répéter ça, ce n'est pas vrai.
Et si c'est vrai, c'est uniquement pour une version de debug.
Hors le mainteneur n'a pas fait sa bourde uniquement sur la version de debug.
Enfin, si c'était pertinant à faire, l'upstream l'aurait fait.
[^] # Re: détails techniques et exploits
Posté par briaeros007 . Évalué à 3.
Certainement plus que dire (répeter jusqu'a plus soif devrais je dire)
"il savait absolument pas ce qu'il faisait", vu qu'il a pointé du doigt le problème d'entropie du code.
Et si c'est vrai, c'est uniquement pour une version de debug.
pas totalement vrai ce que tu dis, il acceptait pour le debugging AUSSI des applications contenants openssl.
Regardons donc les liens que j'ai donné, on voit :
Not much. If it helps with debugging, I'm in favor of removing them.
> (However the last time I checked, valgrind reported thousands of bogus
> error messages. Has that situation gotten better?)
I recently compiled vanilla OpenSSL 0.9.8a with -DPURIFY=1 and on Debian
GNU/Linux 'sid' with valgrind version 3.1.1 was able to debug some
application using both TLS/SSL as S/MIME without any warning or error
about the OpenSSL code. Without -DPURIFY you're indeed flooded with
warnings.
So yes I think not using the uninitialized memory (it's only a single
line, the other occurrence is already commented out) helps valgrind.
Oh tiens ca alors, ca parle pas que du debugage interne à openssl mais aussi de tous les autres codes qui utilisent openssl (et qui donc ne travaillent pas sur une version d'openssl de debug. Quand tu debug ton code, tu travaille pas sur une version de debug de libc6 , si ?)
alors je suis d'accord que le dvp debian a fait des merdouilles, que les dev d'openssl ont pas forcément vu tous les problèmes, mais un moment faut arrêter de dire "Il sait absolument pas ce qu'il faisait", et "il a tout fait tout seul dans son coin".
Enfin, si c'était pertinant à faire, l'upstream l'aurait fait.
Pas forcément : il n'y a pas de bug a proprement parlé. La criticité de l'opération est très faible. Donc on voit passer sa sur la mailing list, on se dis "a pas con", et finalement on oublie de reporter ça. Comme ça ne corrige pas de bugs à proprement parler, on oublie relativement facilement, et on se précipite pas pour pousser tout upstream.
La ou les dvp de debian ont merdé, c'est lors du push des patchs vers l'upstream, et ca je suis bien d'accord.
[^] # Re: détails techniques et exploits
Posté par IsNotGood . Évalué à 1.
QU'IL NE LE FASSE PAS !
> il acceptait pour le debugging AUSSI des applications contenants openssl.
Il a dit "I'm in favor of removing them". Il n'a pas dit "OK, ça roule ma poule".
Il y a un autre développeur OpenSSL qui répond :
On May 1, 2006 03:14 pm, Kurt Roeckx wrote:
> The code in question that has the problem are the following 2
> pieces of code in crypto/rand/md_rand.c:
>
> 247:
> MD_Update(&m,buf,j);
>
> 467:
> #ifndef PURIFY
> MD_Update(&m,buf,j); /* purify complains */
> #endif
There's your first clue, build with -DPURIFY :-)
Cheers,
Geoff
Mais le "247: MD_Update(&m,buf,j);" est devenu "/* MD_Update(&m,buf,j); */" sans que le développeur OpenSSL le savent.
Regarde la version 199 :
http://svn.debian.org/wsvn/pkg-openssl/openssl/trunk/crypto/(...)
C'est :
/** Don't add uninitialised data.
MD_Update(&m,buf,j); MD_Update(&m,buf,j);
*/
Ceci n'a jamais été validé. Et c'est ça qui pose problème.
> I recently compiled vanilla OpenSSL 0.9.8a with -DPURIFY=1 and on Debian
> etc
Il n'est pas développeur OpenSSL.
Le mainteneur Debian a fait une connerie. Je ne demande pas une "lapidation". Mais il a fait une connerie et ça peut arriver à toi ou à moi.
Il faut reconnaitre qu'il a fait une connerie. Je ne demande pas qu'il arrête d'être mainteneur !
Si tu ne reconnais pas qu'il y a connerie, tu ne remets pas en cause. Si tu reconnais qu'il y a une connerie, ben tu ne mets pas en place une solution. Par exemple il ne faut plus toucher au "noyau" OpenSSL sans que le patch soit approuvé en upstream (donc il doit être upstream). Etc.
Quand MS fait une connerie, on ne lui cherche pas d'excuses bidons. MS a fait une connerie, point barre. (Ici il faut évidemment distinguer "connerie" de manoeuvre volontairement mal intentionnée).
Parce qu'en gros tu nous dis "tout va bien, tout c'est passé normalement, et ça va recommencer car il n'y a pas de raison qu'on revoir notre façon de faire".
C'est inacceptable.
[^] # Re: détails techniques et exploits
Posté par briaeros007 . Évalué à 1.
QU'IL NE LE FASSE PAS !
euh .. tu sais voir l'ironie ?
Visiblement pas.
bon pour le reste tu es de mauvaise foi
(- prendre la toute premiere réponse , ou c'est meme marqué "first clue" , et dire "tu vois que c'est que pour le debug", sans prendre en compte les reste du messages
- dire "les dvp d'openssl savait pas ce qu'il fasait alors qu'il avait expliqué , ...
- ne pas savoir lire (inverser celui qui dis "pour moi pas de blem" et celui qui dis "j'ai fait des test")
et je ne perdrais pas plus de temps sur ce sujet avec toi.
Parce qu'en gros tu nous dis "tout va bien, tout c'est passé normalement, et ça va recommencer car il n'y a pas de raison qu'on revoir notre façon de faire".
Arrête de fumer pépé, et apprend à lire.
Ce que je dis c'est que le problème est partagé, et pas seulement celui du "bouh méchant dvp debian qui sait pas faire son boulot".
C'est inacceptable.
Et tu vas faire quoi ? Prendre la tapette a mouche et taper sur les méchants dvp de debian que tu aime pas , parce qu'ils sont pas de fedora ?
Taper sur les gens dont tu arrive pas à comprendre les commentaires ?
[^] # Re: détails techniques et exploits
Posté par IsNotGood . Évalué à 2.
Désolé :-)
J'avais vu que j'avais écrit une connerie, mais j'ai oublié de corriger.
> bon pour le reste tu es de mauvaise foi
Non.
> Et tu vas faire quoi ? Prendre la tapette a mouche et taper sur les méchants dvp de debian
L'erreur de Debian n'est pas innaccèptable. Ne pas la reconnaitre l'est.
[^] # Re: détails techniques et exploits
Posté par briaeros007 . Évalué à 1.
Je la reconnais, mais pas en disant "C'est que des gros naze tout est de leur faute".
Par ex je suis 100% d'accord avec l'auteur d'un blog donné plus bas par Jean-Philippe Garcia Ballester
http://blog.drinsama.de/erich/en/linux/2008051401-debian-ope(...)
Il indique bien que debian a fait des fautes, mais certainement pas "fait absolument n'importe quoi".
[^] # Re: détails techniques et exploits
Posté par Étienne . Évalué à 4.
Ce n'est pas ce que signifie "If it helps with debugging, I'm in favor of removing them. " que je traduit par "si ça aide au débuggage, je suis d'accord pour les supprimer". Et non pas "je suis d'accord pour les supprimer en version debug".
[^] # Re: détails techniques et exploits
Posté par Anonyme . Évalué à 3.
- il parle de retirer des erreurs valgrind pour aider à debugger
- il ne precise pas qu'il est mainteneur debian, ou que ces modifications sont destinées à etre redistribuées à beaucoup de monde
- il ne montre pas un vrai patch, il cite juste 2 lignes identiques avec numeros de lignes, en précisant que ces lignes posent probleme avec valgrind, ce qui est faux, seule une des 2 lignes pose probleme (celle qui peut etre retirée sans problème, l'autre non)
Compte tenu de tout ca :
- il est facile de croire que la personne souhaite simplement se recompiler un openssl pour debugger quelquechose
- il est facile de croire qu'il parlait uniquement de la ligne utilisant de la memoire non initialisée (la réponse est parfaitement correcte dans ce cas la)
- n'ayant pas précisé que cette modification était critique (déstinée à etre redistribuée à beaucoup de monde), la personne qui répond ne prend pas forcement le temps de verifier que toutes les affirmations sont exactes
[^] # Re: détails techniques et exploits
Posté par Étienne . Évalué à 2.
Comme dans tous les problème de sécurité, c'est une ensemble de déficiences qui sont à la source du problème :
- Au départ, le code n'est pas suffisamment explicite et utilise entre autre une variable non initialisée comme source d'aléa
- Le mainteneur veut supprimer les erreurs remontées
- Il demande conseil sans expliquer suffisamment ce qu'il veut faire
- Sur la mailing-list openssl-dev on ne lui explique pas suffisamment le fonctionnement
- Il corrige et supprime un peu trop de code (le mieux est l'ennemi du bien)
- Il est tout seul comme mainteneur d'openssl (en fait ils sont 2 mais il semble que le deuxième soit trop occupé) alors que ça fait 2 ans qu'il demande de l'aide ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332498 )
- Il n'y a pas de revue de la security team pour les packages sensible (manque de moyens et de bonnes volontés sans doute).
C'est clair qu'il a fait une grosse boulette, mais le processus a certainement manqué de quelques fusibles.
PS: la liste des erreurs n'est pas exhaustive, on pourrait noter un manque de remontée upstream comme il a déjà été dit
[^] # Re: détails techniques et exploits
Posté par briaeros007 . Évalué à 1.
C'est pas comme si a pas demandé d'avis aux dvp openssl, et c'est pas comme si ils ont pas dis "si ca peut faciliter le debug, pour nous c'est OK".
De plus j'ai quand même du mal à ce qu'on considère la mémoire non initialisé comme du "bon" aléas. Que ca rajoute un peu d'aléas je peux comprendre(et encore, suffit de mettre toute la mémoire dispo a zero (programme utilisateur) avant de lancer openssl!, et hop on a une jolie faille.
ex : je sais que le serveur X génère des clés le soir à 22h. J'ai un compte utilisateur sur ce serveur.
juste avant 22h, je lance un programme qui va écrire des zéro sur toute la mémoire qu'il peut initialiser, puis ensuite la rend.
La probabilité qu'openssl va demander de la mémoire que j'ai initialiser peut etre assez grande (suivant la mémoire dispo, ce qui tourne, ...))
, mais que tout l'aléa dépende de ça, j'avoue que j'ai plus de mal. C'est pas comme si il y avait /dev/random si on veut de l'aléa un peu plus correct ...
Enfin je suis pas un expert, loin de la, et j'ai pas regardé ce que fait openssl mais ca m'a fait tiquer quand meme.
[^] # Re: détails techniques et exploits
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 4.
Ce n'est pas du tout le cas. Voir par exemple : http://blog.drinsama.de/erich/en/linux/2008051401-debian-ope(...)
[^] # Re: détails techniques et exploits
Posté par briaeros007 . Évalué à 1.
(en plus le gars qui fait le blog est tout a fait de mon avis donc ca peut etre que bien XD )
# Debian est coupable mais pas responsable !
Posté par Unixfix le Gaulois . Évalué à -6.
Franchement cela n'est pas très pro mais excusable après tout Debian est une distribution gérée par des bénévoles donc dans un certain sens amateurs.
Ce qui est beaucoup plus gênant c'est le manque évident de contrôle des distributions commerciales dérivée de Debian. Elles cherchent à s'adresser aux professionnels mais visiblement ne contrôlent pas la qualité des composants essentiels pour la sécurité….
[^] # Re: Debian est coupable mais pas responsable !
Posté par Christophe Merlet (site web personnel) . Évalué à 0.
Un packageur décide de modifier un paquet de la plus haute importance sans comprendre ce qu'il fait ne mérite plus de maintenir de paquets. Dans le cas présent l'erreur a des répercussions inadmissibles.
Maintenant les debian user se cherche des excuses et au lieu d'assumer vont chercher les responsabilités ailleurs ou jetent des écrans de fumée et le discrédit sur les autres distribs. C'est inadmissible !
En vrac.
* C'est pas nous, c'est la faute aux dev upstream... sauf que les devs upstream n'ont jamais intégré ce patch !!
* Debian, on est les meilleurs, dés qu'on a vu le bug on a fait un paquet corrigé. Réussir a dire ça sans mourrir de honte, faut franchement n'avoir aucune fierté :(
* Debian est plus secure que les autres distribs car on a une blacklist des clés pourraves. Là encore oser pourrir nommément les autres distribs à cause de sa propre incurie, faut oser.
Ce genre de bug serait arrivé chez Microsoft, je raconte pas comment il se fairait incendier à raison. c'est arrivé à Debian et ses dérivés, il faut que les devs debian assument.
[^] # Re: Debian est coupable mais pas responsable !
Posté par Unixfix le Gaulois . Évalué à -5.
Il ne faut pas oublier que l'on utilise Debian à ses risques et périls. Personne ne garantit quoique ce soit .....
Il est certain que certaines distributions commerciales dévivées voulant se lancer dans le marché professionnel sont touchées. Mais c'est en parti de leur faute. Le temps ou Debian était une référence en terme de sécurité appartient au lointain passé. Reprendre le code sans le vérifier est autrement coupable.....
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.