Articles précédents : Logiciel
- [22] La SuSE 9 bientôt disponible
- [55] Lindows soutient financièrement Mozilla Composer
- [51] Sortie de DicOOo 1.0
- [92] Sortie de Gaim 0.69 et 0.70
- [10] Sortie de la Sourcemage 0.7
- [59] Slackware 9.1
- [14] Pourquoi utiliser les logiciels libres et OpenSource ?
- [115] Samba 3 est sorti
- [22] StarOffice 7 est sorti
- [39] Sortie de la Knoppix 3.3
Liens connexes
- Le site d'OpenSSL (991 hits)
- Les vulnérabilités d'OpenSSL (902 hits)
Dépêche modérée par
Toutes les versions inférieures à 0.9.6j et 0.9.7b sont affectées.
Il est recommandé de passer à la version 0.9.7c ou 0.9.6k et de recompiler les programmes liés statiquement à OpenSSL.
![[en]](../../../images/en.png)
Le site d'OpenSSL (991 hits)-
Les vulnérabilités d'OpenSSL (902 hits)
> Lire les commentaires (49 commentaires, moyenne: 3,4).
Re: Vulnérabilités dans OpenSSL
Des packages OpenSSL 0.9.7c sont disponibles pour Slackware 9.1 et slackware-current depuis 2 heures et demi environ. Par contre, il va falloir attendre plusieurs heures pour que les miroirs se mettent à jour, et vu qu'ils sont surchargés depuis la sortie de Slackware 9.1, je vous suggère de mettre à jour vous-même OpenSSL si votre site est sensible.
-
[^]Re: Vulnérabilités dans OpenSSL
Posté par Rémi Hérilier (page perso, ) le 01/10/2003 à 12:35. (lien). Évalué à 8.En effet, les ftp sont plutôt encombrés par l'arrivée de la Slackware 9.1 mais bon il n'y a pas que le ftp dans la vie ... ya aussi rsync que moins de monde utilise :-)
Une petite synchro, un coup de upgradepkg et hop !
Il y a deux petits scripts bien sympathiques sur le forum de Slackware Francophone à l'adresse http://slackware.tuxfamily.org/forum/viewtopic.php?t=37(...) (au premier tiers de la page).
À noter que dans slackware-current sont aussi arrivés :
- perl 5.8.1
- samba 3.0
- xfce 4.0
bonheur quand tu nous tiens :-)
bon rsync ;-)
-
[^]Re: Vulnérabilités dans OpenSSL
Posté par Rémi Hérilier (page perso, ) le 01/10/2003 à 12:53. (lien). Évalué à 1.Avec ma veine légendaire, je viens de répondre à la personne qui a fait les dits scripts :-))
En tout cas, merci beaucoup :-)
Re: Vulnérabilités dans OpenSSL
Des updates pour la Mandrake 9.2 (qui n'est pas encore disponible) sont aussi déjà la depuis hier soir (cf ftp://ftp.lip6.fr/pub/linux/distributions/mandrake/updates/9.2/RPM(...) par exemple)
-
[^]Re: Vulnérabilités dans OpenSSL
Posté par Paul POULAIN (page perso, ) le 01/10/2003 à 08:16. (lien). Évalué à 2.ceux pour la MDK 9.1 & consorts sont aussi sortis.
-
[^]Re: Vulnérabilités dans OpenSSL
Posté par dawar (page perso, ) le 01/10/2003 à 12:01. (lien). Évalué à 3.itoo pour debian : Get:1 http://security.debian.org(...) stable/updates/main libssl0.9.6 0.9.6c-2.woody.4 [462kB]
-
[^]Re: Vulnérabilités dans OpenSSL
Posté par Pascal Terjan (Jabber id, page perso, ) le 01/10/2003 à 14:25. (lien). Évalué à 0.Et en testing ?
-
[^]unstable si pressé
Posté par free2.org (page perso, ) le 02/10/2003 à 11:36. (lien). Évalué à 1.il te faudra peut-etre télécharger la version d'unstable si tu es pressé, car il y a une "quarantaine" + ou - longue (écourtée en cas de sécurité) avant qu'un paquet puisse aller dans testing (absence de bug grave à vérifier d'abord, dépendances)
j'ai une page qui explique comment mélanger stable/testing/unstable:
http://free2.org/d/(...)-
[^]Re: unstable si pressé
Posté par Pascal Terjan (Jabber id, page perso, ) le 05/10/2003 à 20:56. (lien). Évalué à 1.Ah et par contre en stable ils sortent le paquet sans test ?
Je ne comprend pas trop comment ca peut etre systematiquement beaucoup plus rapide pour la version stable que j'aurais jugée ne devoir recevoir des nouveau paquets super testés justement !-
[^]Re: unstable si pressé
Posté par Fanboy Scout () le 05/10/2003 à 21:00. (lien). Évalué à 1.d apres des sources sures , c est parce que y a que la security team qui a fait l'acquisition d une licence IPOT
-
-
-
-
-
-
[^]Gentoo, ça criant
Posté par Brice Arnould ( un_brice ) (page perso, ) le 01/10/2003 à 12:53. (lien). Évalué à 2.~.~
Gentoo est encore à la traine: l'ebuild de la 0.96k est distribué, et depuis hier. Mais marqué instable: pour l'utiliser, il faut l'éditer à la main ou alors spécifier son numèro de version demander à utiliser une version instable... sur le bugzilla ils prévoient le passage à la 0.97c dans quelques jours. Et en attendant, rien.
Je me rappelle que lors des dernières failles du noyau, ils avaient mis 1 mois pour intègrer les patchs à leur noyeau.
Et après il viennent parler d'une "hardened Gentoo"... ça me fait rire, même en tant qu'adepte de cette distrib.
Vivement Zynot ! (bon, oké, ça à pas l'air d'avancer trop vite en ce moment)--
Respect à RMS.-
[^]Re: Gentoo, ça criant
Posté par j () le 01/10/2003 à 14:01. (lien). Évalué à 4.Barf il faut relativiser.
Est-ce-qu'il existe des exploits publics pour ces failles ? Non, aucun à ma connaissance.
Est-ce-que l'on peut être surs, 5 minutes après l'annonce de la nouvelle version, qu'elle peut être immédiatement installée sur tous les serveurs en prod sans rien casser ? Non.
Si tu tiens à passer immédiatement à la nouvelle version sur ta Gentoo, tu peux, le paquetage est prêt. Il suffit d'admettre que tu souhaites installer quelque chose qui n'a pas encore été complétement testé. Un délai de quelques jours avant de marquer ces paquetage "stable" me paraît tout à fait raisonnable.-
[^]Re: Gentoo, ça criant
Posté par j () le 01/10/2003 à 15:15. (lien). Évalué à 4.En plus tu es de mauvaise foi car c'est marqué comme stable depuis ce midi.
Et l'advisory officiel de Gentoo vient d'être envoyé sur Bugtraq et FD.-
[^]Re: Gentoo, ça criant
Posté par Brice Arnould ( un_brice ) (page perso, ) le 01/10/2003 à 15:35. (lien). Évalué à 3.°_°
Je viens de faire un "emerge sync".
emerge -p openssl
[ebuild UD] dev-libs/openssl-0.9.6j [0.9.6k]
...
http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-libs/openssl/openssl-(...)
...
Si je suis de mauvaise fois, les mirroirs sont plus à jour que le CVS.
Mais non! L'histoire est encore plus drôle.
Lis l'historique du CVS: ils avaient oublié de spécifier que le package était disponible aussi pour sparc, et du coup ils ont rajoutté le mot clef "sparc" après coup.
Sans penser à mettre le "~sparc" qui aurait indiqué que c'est une version instable (sur cette architecture) !
Au passage, notte que tu as approuvée l'idée de Gentoo de ne pas mettre à jour la librairie, jusqu'à ce que tu crois qu'elle avait été mise à jour (alors qu'elle l'est par erreur, et seulement sur cette architecture). Dans ces conditions, m'accuser de mauvaise fois...--
Respect à RMS.
-
-
[^]Re: Gentoo, ça criant
Posté par Brice Arnould ( un_brice ) (page perso, ) le 01/10/2003 à 15:18. (lien). Évalué à 3.Est-ce-qu'il existe des exploits publics pour ces failles ? Non, aucun à ma connaissance.
Merveilleux: on est à l'abris des scripts kiddies ! (à priori)
Je serais très surpris que personne n'arrive à exploiter cette faille dans les trois prochains jours.
Est-ce-que l'on peut être surs, 5 minutes après l'annonce de la nouvelle version, qu'elle peut être immédiatement installée sur tous les serveurs en prod sans rien casser ? Non.
Passer de la version 0.9.6j à la 0.9.6k, sachant que cette dernière consiste juste en 4 correctifs de sécurité... disons que c'est moins risqué que de garder une version vérolée.
C'est d'ailleurs ce que se sont dit les mainteneurs des autres distros, semble-t'il.
Si tu tiens à passer immédiatement à la nouvelle version sur ta Gentoo, tu peux, le paquetage est prêt. Il suffit d'admettre que tu souhaites installer quelque chose qui n'a pas encore été complétement testé. Un délai de quelques jours avant de marquer ces paquetage "stable" me paraît tout à fait raisonnable.
Le fait est qu'un type qui fait confiance aux gestionnaires de sa distro (comme moi jusqu'à recement) se trompe.
Un type qui installe un matin une gentoo avec la dernière version des packages doit en plus lire la liste des failles récentes et appliquer les mises à jour manuellement. Ceci requierant la modification/restauration du fichier de conf, pour evitter de se faire jetter comme quoi le package est experimental (ou alors il est habitué aux errements de Gentoo, et il a des scripts ou alias à portée de main).
Et après, chaque mise à jour automatique essaieras en plus de passer tous ses packages en stable ou instable. Reste la (contraignante) possibilité d'afficher la liste les packages à mettre à jour, puis de les installer un par un. Mais alors ces packages ne seront pas supprimés par depclean, et ce même si ils ne ne sont plus utiles à aucun programe, car ils seront considérés comme utiles par eux mêmes. Jusqu'au prochain formatage.
Pour moi, cet exemple, celui du kernel, et d'autres (pas seulement au niveau des packages) ne relèvent pas de la prudence mais plutôt d'un grave problème d'organisation. Il n'y a même pas de règles régissant le passage d'un package instable en stable !--
Respect à RMS.-
[^]Re: Gentoo, ça criant
Posté par j () le 01/10/2003 à 15:26. (lien). Évalué à 2.Pourquoi tu ne postes ceci sur les forums Gentoo ?
-
[^]Re: Gentoo, ça criant
Posté par Brice Arnould ( un_brice ) (page perso, ) le 01/10/2003 à 15:41. (lien). Évalué à 0.Parce que les dirigeants de Gentoo ont déjà démontrée leur aptitude à ne pas écoutter la comunautée, et que mon post ne changerais rien.
Et aussi parce que je prefère pointer du doigt les défaut de l'organisation actuelle, et ainsi pousser à un changement un profondeur, que d'essayer de l'aider à se rendre crédible.
Mais surtout parce que je parle très mal anglais. -_^--
Respect à RMS.
-
-
[^]Re: Gentoo, ça criant
Posté par GnunuX (Jabber id, page perso, ) le 02/10/2003 à 06:37. (lien). Évalué à 1.> C'est d'ailleurs ce que se sont dit les mainteneurs des autres distros, semble-t'il.
Ou les mainteneurs d'autre distros font confiance a ceux qui maintiennent le package. L'instabilité des packages ne vient pas de l'instabilité des logiciels mais du systeme de dépendance ...
-
-
-
[^]Re: Gentoo, ça criant
Posté par Mathieu Pillard (page perso, ) le 01/10/2003 à 23:58. (lien). Évalué à 1.> Je me rappelle que lors des dernières failles du noyau, ils avaient mis 1 mois pour intègrer les patchs à leur noyeau.
1/ tu es libre de ne pas prendre gentoo-sources, yen a plein d'autres.
2/ pour gentoo-sources, il existe pfeifer-sources qui est la version de developpement, bcp plus a jour, pour les pressés.
3/ gentoo-sources inclus grsecurity
-
librairie de cryptographie
Zut il me semblait que c'était une bibliothèque.
http://www.42-networks.com/faq/library.html(...)
-
[^]Bibliothèque !
Posté par Christophe Morvan (page perso, ) le 01/10/2003 à 08:14. (lien). Évalué à 1.\o/ !
Je ne suis pas tout seul !
-
[^]Re: librairie de cryptographie
-
[^]Re: librairie de cryptographie
Posté par Aurélien Girard () le 01/10/2003 à 11:47. (lien). Évalué à 2.et moi qu'il s'agissait de chiffrement et non de cryptographie ...
--
BeOS le faisait il y a 10 ans.-
[^]Re: librairie de cryptographie
-
-
[^]Re: librairie de cryptographie
patches "exec shield" et "systrace"
pour ceux qui aiment modifier leur noyau, c'est le moment de rappeler que la plupart des failles liées à des débordements de tampon (buffer overflow) sont bégnines avec le patch "exec shield" de Ingo Mollnar
et pour les paranos, la quasi totalité des failles, quelque soit leur nature, sont confinables en lancant chaque programme internet dans une sandbox (interactive donc facile à paramétrer et elle nous alerte en cas d'anomalie) du patch systrace. Le surcout total en CPU est minime (de l'ordre de 1%).
tout ceci n'empeche évidemment pas de mettre à jour dès que possible openssl
-
[^]Re: patches "exec shield" et "systrace"
Posté par FRLinux (page perso, ) le 01/10/2003 à 07:54. (lien). Évalué à 1.Petite question par rapport a ce patch, si tu installes des kernels avec grsecurity, il devient pas vraiment necessaire non ?
Steph-
[^]grsecurity/execshield
Posté par free2.org (page perso, ) le 01/10/2003 à 08:08. (lien). Évalué à 2.en ce qui concerne les overflows je crois que exec shield est plus complet: il controle les variables stack, heap et static
-
[^]Re: grsecurity/execshield
Posté par yoho (page perso, ) le 02/10/2003 à 10:30. (lien). Évalué à 2.Non grsec vérifie cela aussi mais ces extensions ne sont pas activées par défaut dans la mandrake : il faut recompiler le noyau. Le BIG inconvénient si on met la sécurité maximale dans GRSec, c'est que certaines applications se plantent (sans dommage pour le système, mais elles ne fonctionnent pas quand même). C'est notamment le cas du X Window System ...
-
[^]option de recompilation ?
Posté par free2.org (page perso, ) le 02/10/2003 à 18:43. (lien). Évalué à 2.il me semble qu'il y a une option dans gcc pour lui interdire de mettre du code exécutable dans les même zones mémoires que les variables, ce qui est la principale incompatibilité avec ces patches
-
-
-
-
[^]xsupervisor et fireflier
Posté par free2.org (page perso, ) le 01/10/2003 à 07:57. (lien). Évalué à 5.pour être complet en matière de sécurité je cite aussi les programmes xsupervisor pour X, et fireflier (firewall interactif) pour iptables
En Anglais dans le texte
Il y a une petite erreur dans la news, toutes les versions d'OpenSSL sont vulnérables à un des problèmes, je cite : "1. Certain ASN.1 encodings that are rejected as invalid by the parser
... This issue does not affect OpenSSL 0.9.6"
Alors que la seconde affecte bien toutes les versions : "All versions of OpenSSL up to and including 0.9.6j and 0.9.7b and all
versions of SSLeay are affected."
Steph
Zut encore une faute :o)
Je cite :
All versions of OpenSSL up to and including 0.9.6j and 0.9.7b and all
versions of SSLeay are affected
On doit donc lire dans la news :
Toutes les versions inférieures ou égales à 0.9.6k et 0.9.7c sont affectées.
Sinon la phrase suivante :
Il est recommandé de passer à la version 0.9.7c ou 0.9.6k
n'a plus de sens !
-
[^]Re: Zut encore une faute :o)
Posté par Meister (page perso, ) le 01/10/2003 à 11:36. (lien). Évalué à 1.La logique a du me faire encore un tour.
-
[^]Re: Zut encore une faute :o)
Posté par asailor () le 02/10/2003 à 07:35. (lien). Évalué à 1.Mais que fait la police ?
Maintenant c'est « corrigé » comme cela :
Toutes les versions inférieures à 0.9.6j et 0.9.7b sont affectées.
Alors que ça devrait être :
Toutes les versions inférieures ou égales à 0.9.6j et 0.9.7b sont affectées.
Ok, je vais faire simple, tu choisis :
1/
Toutes les versions inférieures à 0.9.6k et 0.9.7c sont affectées.
2/
Toutes les versions inférieures ou égales à 0.9.6j et 0.9.7b sont affectées.
Copier-coller et hop !
;-)-
[^]Re: Zut encore une faute :o)
Posté par Nap () le 02/10/2003 à 07:56. (lien). Évalué à 0.ça dépend si on prend le terme "inférieur" comme inférieur strict ou pas... dans les maths francaises il y a toujours l'ambiguïté
en revanche chez les anglais elle n'y est pas, et pour dire "inférieur ou égal" ils disent "non supérieur" je crois
-
-
Re: Vulnérabilités dans OpenSSL
Toutes les versions inférieures ou égales à 0.9.6k et 0.9.7c sont affectées.
(...)
Il est recommandé de passer à la version 0.9.7c ou 0.9.6k
le "ou égales" n'est t-il pas de trop dans la phrase? ou est-il conseilllé de mettre à jour sur une version affectée?
Soyons précis dans nos traductions, merci.
Je suis exaspéré de voir partout "malicioux" traduit en "malicieux". "malicious" est un faux-ami qui se traduit par "méchant" ou "malveillant" et surtout pas par "malicieux". Désolé mais un ver, un virus... c'est pas franchement malicieux.
Dans la même série (un peu plus discutable peut-être), il y a "to forge" qui certes peut se traduire par "forger" (du métal) mais qu'on devrait plutôt traduire par "contrefaire". Pour moi "forged IP packets" se traduit par "paquets IP contrefaits" et non "forgés"...
Question ouverte aux modérateurs : ne pourrait-on pas mettre en place un système permettant de proposer des corrections sur le style ou l'orthographe ? Ceci délesterait les forums des messages sybillins du style "s/malicieux/malveillant/g"...
-
[^]Re: Soyons précis dans nos traductions, merci.
Posté par AP () le 01/10/2003 à 09:11. (lien). Évalué à 3.Vous aurez corrigé : s/malicioux/malicious/.
Dans la même veine il serait sympathique de pouvoir corriger/supprimer ses propres contributions... :) Rien de plus horrible qu'un pinailleur tel que moi qui par étourderie s'expose au feu nourri d'autre pinailleurs (pires, sans doute :).-
[^]Re: Soyons précis dans nos traductions, merci.
Posté par asailor () le 01/10/2003 à 09:14. (lien). Évalué à 2.il serait sympathique de pouvoir corriger/supprimer ses propres contributions
100% ok, mais ça pose un problème de cohérence avec le thread...
(imagine que tu retires ce que d'autes ont commenté)-
[^]Re: Soyons précis dans nos traductions, merci.
Posté par tene (page perso, ) le 01/10/2003 à 09:23. (lien). Évalué à 2.Et un truc genre, le commentaire avec en dessous la liste des correctinons appliquées?
Ceci dit, le problème est toujours le même, le site ne bouge pas des masses, et il semble pas que les admins soit super réactif... de là à dire qu'il s'en foute de leur communauté, je ne franchirai pas ce pas... mais je finis par me poser des questions....
-
[^]Re: Soyons précis dans nos traductions, merci.
Posté par a_jr () le 01/10/2003 à 10:15. (lien). Évalué à 1.On peut peut-etre contourner cela en gardant l'historique du post, visible par tous.
Ainsi, si qq dit "machin c'est genial" et qu'il change en "machin c'est nul", on verra tout de suite que le gars n'est pas fiable.
On peut aussi rajouter un truc dans le genre ou une correction coute un [-], mais je ne sais pas si l'effet serait benefique (ca peut faire reflechir avant de poster) ou nefaste (du coup, on eviterait de corriger, pour ceux qui font gaffe a leux XP)
On peut aussi rajouter un truc qui me semble important avec l'historique: mettre en evidence qu'il y a un historique sur le post, combien il y a eu de modifs, et quelle taille fait la modif. 2 lettres modifiees signifient generalement une correction orthographique, alors que 2 paragraphes changes, supprimes ou rajoutes signifient un changement majeur de signification du post.
Il faudrait aussi peut-etre mettre en evidence qu'un post qui repond a un autre qui a ete modifie, repond a une ancienne version du post et non pas a celle visible.
Bref, ca necessite beaucoup de modifs. Et comme d'hab, y'a qu'a, mais faut qq pour le faire.
Le bonjour chez vous,
Yves
-
[^]Re: Soyons précis dans nos traductions, merci.
Posté par Benjamin Michotte (page perso, ) le 01/10/2003 à 13:00. (lien). Évalué à 1.ce qu'il faudrait, c'est un systeme de news à la wiki ;)
(comment ca, c'est pas faisable ?)
-
-
-
[^]Re: Soyons précis dans nos traductions, merci.
Posté par gnap gnap (page perso, ) le 01/10/2003 à 09:15. (lien). Évalué à 8.En fait l'origine du terme malicieux est la même : le malin, le diable, est malfaisant... et malicieux.
Etre malicieux dans un sens plus ancien, c'était donc associé à une certaine malfaisance -- quoi que pas nécessairement si péjorativement connoté. Mais cette connotation péjorative est moindre en Français, de nos jours.-
[^]Re: Soyons précis dans nos traductions, merci.
Posté par Aurélien Girard () le 01/10/2003 à 11:49. (lien). Évalué à 2."cette connotation péjorative est moindre en Français, de nos jours."
Je trouve que c'est donc une bonne idée de parler de "programmes malicieux" pour remettre ce terme au goût du jour.--
BeOS le faisait il y a 10 ans.-
[^]Re: Soyons précis dans nos traductions, merci.
-
-
Re: Vulnérabilités dans OpenSSL
Et FreeS/WAN dépend-il d'OpenSSL ? Si c'est le cas, c'est super grave pour mon réseau !
-
[^]Re: Vulnérabilités dans OpenSSL
Cette page a été générée par Templeet en 0.2303s (dont 0.0739 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
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.