Articles précédents : Sécurité
- [44] Effets pervers du modèle de sécurité BitFrost de OLPC
- [51] Un pas de plus vers la démocratisation du sftp
- [57] Important bug de sécurité sur noyau 2.6.17 à 2.6.24
- [2] Pare-feu authentifiant : sortie de NuFW Live
- [19] Nulog 2 est disponible
- [31] Dossier sur le renforcement des fonctions de sécurité du noyau sur Secuobs.com
- [3] SecUbuLive un Live CD GNU/Linux personnalisable et facile à mettre à jour
- [2] Documentation non officielle en français pour Scapy sur Secuobs.com
- [37] Orange implémente l'OpenID sur son portail Web
- [17] Compte rendu en temps réel de l'atelier Netfilter 2007
Liens connexes
- Le Debian Security Advisory (815 hits)
- Dowkd.pl - A télécharger absolument en cas de doutes ! (1809 hits)
- Metasploit a généré les clefs faibles (717 hits)
- Journal Linuxfr déja paru à ce sujet (877 hits)
- Wiki Debian :à lire si vous ne savez pas quoi faire (851 hits)
- ... (244 hits)
Dépêche modérée par
Dépêche éditée par
Sécurité : Découverte d'une faille de sécurité critique dans OpenSSL de Debian
Posté par Amaury (). Modéré le 15 mai 2008.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 ?
- Mettre à jour votre distribution Debian pour installer les nouveaux paquet.
- 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...
- lire le wiki Debian http://wiki.debian.org/SSLkeys qui vous guidera pas à pas en fonction des logiciels installés sur votre machine.
NdM : lire également les articles sur Planet Debian-Fr.
Le Debian Security Advisory (815 hits)
Dowkd.pl - A télécharger absolument en cas de doutes ! (1809 hits)
Metasploit a généré les clefs faibles (717 hits)
Journal Linuxfr déja paru à ce sujet (877 hits)
Wiki Debian :à lire si vous ne savez pas quoi faire (851 hits)
... (244 hits)
> Lire les commentaires (329 commentaires, moyenne: 2,2).
Fiabilité de dowkd.pl ...
> 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.
-
[^]Re: Fiabilité de dowkd.pl ...
Posté par Romain Be. () le 15/05/2008 à 14:11. (lien). Évalué à 4.Ha la la, dès qu'on parle sécurité, tous les excès arrivent..
Enfin, un faux positif est jamais mauvais en soi, tandis que les faux négatifs sont simplement possibles, mais pas prouvés.
Bref, tout se joue à la parano.
A noter que les clefs générées sur un système pre-etch sont fiables. C'était le cas sur tous mes serveurs, qui dataient de sarge ou plus, et c'est surement aussi le cas pour d'autres..
debian
debian sapu saipahaleatoire.
Un peu d'humour
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
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
-
[^]Re: fail2ban
Debian ou dérivé
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.
-
[^]Re: Debian ou dérivé
Posté par nyquist () le 15/05/2008 à 14:51. (lien). Évalué à 10.De toutes façons, ils y comprendrai rien les utilisateurs d'ubuntu... ;)
Plus sérieusement, si il font les mises à jours de sécurité régulièrement leur clé sont déjà supprimé (avec tous les problèmes que ça peut engendrer).
Par contre je suis curieux de savoir quand Xandros corrigera le problème.-
[^]Re: Debian ou dérivé
Posté par brunus (page perso, ) le 15/05/2008 à 15:20. (lien). Évalué à 8.Bin justement...
Sur une Dapper Drake, la LTS 6.06, la version de openssl est 0.9.8a.
Hors sur l'advisory Debian : The first vulnerable version, 0.9.8c-1, was uploaded to the unstable distribution on 2006-09-17
En tant que crétin d'utilisateur d'Ubuntu, ce que je comprend, c'est que ma LTS n'est pas affectée par ce bug, et que j'ai eu raison de ne pas immédiatement faire la mise à jour vers la nouvelle LTS.
J'ai bon ? On alors comme je suis un utilisateur d'Ubuntu je n'ai rien compris...-
[^]Re: Debian ou dérivé
Posté par case42 (page perso, ) le 15/05/2008 à 15:42. (lien). Évalué à 4.Je dirais que tu as presque bon, la dernière bonne question a se poser est:
est-ce que le Bug a été introduit dans Dapper par une mise a jour ulterieure de OpenSSL, ou en est-elle toujours exempt? Et si le Bug y est, as-tu généré des clefs après son introduction?
Mais si Dapper ne souffre pas de ce bug, un bon point pour la LTS d'Ubuntu...-
[^]Re: Debian ou dérivé
Posté par brunus (page perso, ) le 16/05/2008 à 09:48. (lien). Évalué à 3.Oui effectivement je me suis aussi posé la question...mais je ne vois pas pourquoi le mainteneur du paquet Ubuntu aurait patché la version récupérée au moment du freeze de Sid, avec un correctifs qui a été injecté dans Sid dans une version ultérieure du paquet.
Mais je vais essayer de trouver l'info...j'ai vraiment besoin de savoir.
-
-
[^]Re: Debian ou dérivé
Posté par nyquist () le 15/05/2008 à 18:56. (lien). Évalué à 4.En tant que crétin d'utilisateur d'Ubuntu, ce que je comprend, c'est que ma LTS n'est pas affectée par ce bug, et que j'ai eu raison de ne pas immédiatement faire la mise à jour vers la nouvelle LTS.
J'ai bon ? On alors comme je suis un utilisateur d'Ubuntu je n'ai rien compris...
Tu as bon...
Maintenant ce pose à moi un dilemme, si les utilisateurs pas si crétins d'ubuntu comprennent, ça veut dire que c'est moi le crétin d'avoir dit ça...
Dur!
De toute façon je suis aussi un utilisateur d'ubuntu donc dans tous les cas je suis mal barré...-
[^]Re: Debian ou dérivé
Posté par brunus (page perso, ) le 16/05/2008 à 10:03. (lien). Évalué à 2."De toute façon je suis aussi un utilisateur d'ubuntu donc dans tous les cas je suis mal barré..."
Tout dépend...t'es tu empressé de mettre à jour tes LTS ou as tu sagement attendu la 8.04.1 ? ;-)
Je crois que c'est simplement de la chance...Dapper Drake est issue d'un freeze de Sid qui a eu lieu un an avant l'injection du bug dans Debian Unstable...that's all. Hazard des calendriers tout ça...
Si j'avais souhaité avoir un système bien plus sécurisé, qu'un dérivé de Debian, il y avait des solutions dans le libre...Je n'ai jamais considéré une Debian comme étant le summum de la sécurité...mais je crois qu'on en parle déjà dans d'autres commentaires, ce n'est pas la peine de lancer un second troll à tête multiples.
-
-
-
-
[^]Re: Debian ou dérivé
Posté par pankkake (Jabber id, page perso, ) le 15/05/2008 à 21:52. (lien). Évalué à 0.Quand j'ai mis à jour mon Ubuntu, j'ai eu un message explicatif et il a régénéré toutes mes clés. Heureusement que je ne m'en sers pas sur ce PC, parce que me voir mes clés virées (quoique j'espère qu'il en fait une sauvegarde quelque part) ça peut poser quelques problèmes.
-
[^]Re: Debian ou dérivé
Posté par g0d0t () le 16/05/2008 à 00:00. (lien). Évalué à 3.Le message en question semblait donner le choix de ne pas regénérer automatiquement. Mais il n'était pas clair, du genre une question où on devrait avoir "Oui" ou "Non" comme possibilités, mais où les choix disponibles n'étaient pas bien adaptés à la question.
-
Mise en perspéctive
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.
-
[^]Re: Mise en perspéctive
Posté par gc (page perso, ) le 15/05/2008 à 14:42. (lien). Évalué à 2.Debian a choisi de communiquer intensément, dans la tradition d'"on ne cachera pas les problèmes".
Ce n'est pas par choix : une fois qu'une faille comme cela est découverte par quelqu'un (hors Debian) qui choisit d'en parler, Debian a l'obligation d'en parler et même intensément, pour ne pas compromettre encore davantage ses utilisateurs, et du coup complètement se décribiliser/ridiculiser.-
[^]Re: Mise en perspéctive
Posté par Romain Be. () le 15/05/2008 à 15:19. (lien). Évalué à 4.Oui, mais cela reste un choix, il existe des tonnes de failles non publiées ou pour lesquelles l'auteur du logiciel a fait le service minimun.
-
[^]Re: Mise en perspéctive
Posté par Christophe Merlet (page perso, ) le 15/05/2008 à 16:21. (lien). Évalué à 4.J'aimerais bien que tu me cites une ou deux failles parmi les "tonnes" non publiées qui inpactent aussi dangereusement la sécurité et la confidentialités des échanges sur Internet et dans les entreprises !
Même la dernière faille vmsplice du kernel est 100 fois moins dangereuse !!
Et ce qui est assez scandaleux ici, c'est que ce n'est pas une faille du développement upstream, mais une faille béante apportée par un développeur externe, visiblement pas expert en cryptographie, au projet pour "corriger" un problème cosmétique de développement logiciel et intégré dans une distribution généraliste.
Ce qui me gène énormément dans cette histoire, c'est l'attitude devs Debian qui cherche à discréditer tout le monde (upstream et autres distributions) au lieu d'assumer simplement leur responsabilité et faire profil bas.-
[^]Re: Mise en perspéctive
Posté par Gniarf () le 15/05/2008 à 16:38. (lien). Évalué à 4.tiens, au hasard, OpenOffice :
http://www.openoffice.org/news/index.html
Security update
Please note that OpenOffice.org version 2.4, released on 27th March, fixed a number of security vulnerabilities. To our knowledge, none of these has been exploited; however, in accordance with industry best practice, we recommend all users upgrade to 2.4.
This information was withheld intially to ensure that all the products derived from the OpenOffice.org codebase had time to include these security fixes before the public announcement of the vulnerabilities.
#Manipulated ODF text documents containing XForms can lead to heap overflows and arbitrary code execution
#Manipulated Quattro Pro files can lead to heap overflows and arbitrary code execution
#Manipulated EMF files can lead to heap overflows and arbitrary code execution
#Manipulated OLE files can lead to heap overflows and arbitrary code execution
ils n'ont pas annoncé ces soucis à la sortie de OpenOffice 2.4 mais bien bien après (à tort ou à raison mais ce n'est pas la question ici)
> Ce qui me gène énormément dans cette histoire, c'est l'attitude devs Debian qui cherche à discréditer tout le monde (upstream et autres distributions) au lieu d'assumer simplement leur responsabilité et faire profil bas.
je n'ai pas lu ça du tout.--
Windows has no users. It has hostages.-
[^]Re: Mise en perspéctive
Posté par Christophe Merlet (page perso, ) le 15/05/2008 à 16:48. (lien). Évalué à 4.En aucune façons les bugs d'OpenOffice sont aussi dangereux que cette faille d'OpenSSL. sur laquelle s'articule toute la sécurité et la confidentialité des échanges sur Internet et en entreprise.
De plus, ce que tu cites ce sont des bugs dans le développement upstream corrigé en upstream et pas des bugs rajoutés par la distributions.
> je n'ai pas lu ça du tout.
Va sur planet.debian.org ... !!!
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.
Toi même, si tu te relis !-
[^]Re: Mise en perspéctive
Posté par Gniarf () le 15/05/2008 à 17:32. (lien). Évalué à 9.ah donc si je recevais un fichier avec des images corrompues et que j'avais un peu trainé à mettre à jour ma 2.3 simplement disons par manque de ressources ou que c'était le week-end je ne risquais rien. ravi d'apprendre que ce n'était pas dangereux. ah zut si, c'était dangereux, juste que c'était un autre vecteur d'attaque, enfin de vulnérabilité. heureusement que je ne reçois que des documents Microsoft Office \o/
et concernant planet.debian.org je
ah non stop, planet.debian.org a autant à voir avec Debian que le blog de ploum a à voir avec Ubuntu. lire ça ou les combats de pissotières sur Usenet, ça n'a d'intérêt que si on aime recevoir des éclaboussures. chacun son trip.
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 !!
je pense que les "upstreams" n'ont rien à voir là dedans mais ce n'est que mon opinion. au pire le dev upstream concerné a mal compris une question posée par un des gars de Debian.
> * 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é :(
c'est quoi qui compte, qu'ils aient vite résolu le problème (et je pense pas que d'autres distributions responsables ou les BSDs auraient fait moins vite) ou des notions de honte ou de fierté dont on n'a absolument rien à foutre dès le lendemain ? si ce genre de gag reste isolé, je n'ai pas de raison sérieuse de leur retirer ma confiance.
> * 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.
j'aimerais savoir comment une autre distribution ou d'autres utilisateurs de openssl aurait résolu la même gaffe sans une telle blacklist et prévenir le reste de la planète. c'est un peu se plaindre qu'on propose une liste de users et de passwords à ne pas utiliser (genre test/test) ou que passwd te crie après si tu mets un mot de passe trop court ou trop simple. oui, on peut s'en passer...
> Toi même, si tu te relis !
je ne sais pas ce que tu prends comme drogue mais tu devrais arrêter tout de suite. et d'ailleurs je ne suis pas "de Debian", et niveau utilisation des distributions je suis laaargement agnostique, j'ai connu Unix avant Windows et en fait presque avant DOS donc bref, si Debian accumulait ce genre de gags j'irais voir ailleurs sans me casser la tête.
tu demandes un exemple et j'en ai proposé un, tu ne le trouves pas pertinent certes ok, là dessus je te conseille une tisane si ça peut soigner tes délires de persécution.--
Windows has no users. It has hostages.
-
-
[^]Re: Mise en perspéctive
Posté par IsNotGood () le 15/05/2008 à 16:52. (lien). Évalué à 0.Il faudrait savoir de quoi tu parles...
Il y des failles de sécurité connues, mais connues d'un petit groupe (ceux en charge de la sécurité). Ses failles sont sous "embargos" tant qu'un correctif n'est pas réalisé ou que personne n'a rendu la faille public ou qu'il n'y a pas un exploit.-
[^]Re: Mise en perspéctive
Posté par Gniarf () le 15/05/2008 à 17:07. (lien). Évalué à 3.et le "responsable disclosure" qui va avec ? il y a d'autres façons de faire, et elles ne sont pas "irresponsables", loin s'en faut.
--
Windows has no users. It has hostages.-
[+] [^]Re: Mise en perspéctive
Posté par IsNotGood () le 15/05/2008 à 17:10. (lien). Évalué à -1.> et le "responsable disclosure" qui va avec ?
Qu'es-ce tu racontes ?
Si t'es assez con de divulguer publiquement une faille non encore connue, ben fait le. Personne ne t'en empêche.
Mais il est d'usage, et intelligent, d'en informer que ceux qui s'occupe de la sécurité.-
[+] [^]Re: Mise en perspéctive
Posté par Gniarf () le 15/05/2008 à 17:21. (lien). Évalué à -2.non mais genre parce que tu crois m'apprendre quelque chose ici, et me convaincre de mon erreur en me traitant de con si je ne suis pas d'accord avec ton auguste personne ?
bah écoute mon petit hein, c'est un vaste débat qui te dépasse largement et je te conseille de laisser ça aux personnes concernées (les white hats, on dira) qui jugeront au cas par cas ce qu'elles doivent faire. parce que, des fois, même prévenu personne corrige après 2 ou 6 mois, et d'autres personnes (les méchants) ont trouvé et utilisent la même faille. ou encore, des fois l'éditeur en question a tout simplement disparu.--
Windows has no users. It has hostages.-
[^]Re: Mise en perspéctive
Posté par IsNotGood () le 15/05/2008 à 17:25. (lien). Évalué à 0.Je dois être très con, car je ne vois toujours pas où tu veux en venir, quel est ton coup de gueule, etc.
Mais ça ne doit être que moi. Tes propos doivent être limpides pour tous les autres.-
[^]Re: Mise en perspéctive
Posté par fredix (Jabber id, page perso, ) le 15/05/2008 à 17:39. (lien). Évalué à 5.il vient de te dire que dans certains cas, tu préviens l'upstream d'une faille qui n'est pas corrigé au bout de N mois (souvent du proprio bien sûr).
Or dans ce cas il est de bon ton de diffuser la faille afin de prévenir les usagers et faire bouger l'upstream...-
[^]Re: Mise en perspéctive
Posté par IsNotGood () le 15/05/2008 à 17:59. (lien). Évalué à 1.> il vient de te dire que dans certains cas, tu préviens l'upstream d'une faille qui n'est pas corrigé au bout de N mois
Comme il connait cette faille si elle n'est pas public ?
> Or dans ce cas il est de bon ton de diffuser la faille afin de prévenir les usagers et faire bouger l'upstream...
Mouaif.-
[^]Re: Mise en perspéctive
Posté par fredix (Jabber id, page perso, ) le 15/05/2008 à 18:09. (lien). Évalué à 1.>Comme il connait cette faille si elle n'est pas public ?
man scriptkiddies-
[^]Re: Mise en perspéctive
Posté par IsNotGood () le 15/05/2008 à 18:10. (lien). Évalué à 4.> man scriptkiddies
Tu n'as pas mieux ?
Si le scriptkiddies la connais, alors la faille est public et même exploité.
On ne parle plus du tout de la même chose.-
[^]Re: Mise en perspéctive
Posté par fredix (Jabber id, page perso, ) le 15/05/2008 à 18:12. (lien). Évalué à 3.> Tu n'as pas mieux ?
man brain-
[+] [^]Re: Mise en perspéctive
Posté par Sébastien FRADE (Jabber id, ) le 17/05/2008 à 13:27. (lien). Évalué à -2.>man brain
tu as pensé à le tester avant de le conseiller?
-
-
-
-
[^]Re: Mise en perspéctive
Posté par wismerhill (page perso, ) le 15/05/2008 à 19:09. (lien). Évalué à 5.> Comme il connait cette faille si elle n'est pas public ?
Tout simplement parce qu'il l'a constatée par hasard (ça arrive) ou suite à un audit de sécurité interne (ça arrive aussi) ou encore parce qu'il a constaté une intrusion/utilisation abusive de son serveur par un cracker qui aura découvert la faille à sa façon (ancien employé qui a introduit en douce une backdoor, vol de code).
Et là je ne parle que de logiciels fermés.
Pour du libre, tu peux faire un vrai audit du code (il y a des boîtes qui font ça) et tomber sur des trucs dont l'upstream ne s'était pas rendu compte.-
[+] [^]Re: Mise en perspéctive
Posté par IsNotGood () le 15/05/2008 à 19:18. (lien). Évalué à -3.> un cracker qui aura découvert la faille à sa façon
Dans ce cas la faille est public !
Même si elle n'est pas annoncé sur les tois, elle est public !
Dans les autres cas, c'est à celui qui a découvert la faille de décider s'il veut la rendre public ou seulement contacter les responsables de la sécurité.
L'usage (ce n'est pas un obligation) veut qu'on contacte uniquement les responsable de la sécurité. Il y aura un "embargo", mais on ne te demande pas de signer un accord pour ne pas divulguer la faille. On compte sur ton intelligence, ta "courtoisie", pour ne pas le faire.-
[^]Re: Mise en perspéctive
Posté par fredix (Jabber id, page perso, ) le 15/05/2008 à 19:32. (lien). Évalué à 1.En quoi une faille découverte par une personne est forcément public ?
Sinon pour le reste pas la peine de te répéter, on dirait que tu viens de découvrir le Net avant-hier et le hacking/cracking hier ...-
[^]Re: Mise en perspéctive
-
-
[^]Re: Mise en perspective
Posté par Yusei () le 15/05/2008 à 20:33. (lien). Évalué à 8.Ton discours est incohérent. Ta définition de "public" change d'un message à l'autre au sein d'un même fil de discution, en fonction de ce qui t'arrange.
Au début, tu dis qu'une faille peut être connue par un petit groupe de gens sans être publique. Mais maintenant, tu prétends que si un cracker la découvre, elle est publique.-
[+] [^]Re: Mise en perspective
Posté par IsNotGood () le 15/05/2008 à 20:52. (lien). Évalué à -1.> Mais maintenant, tu prétends que si un cracker la découvre, elle est publique.
Si un cracker la connait, tu peux supposer que plusieurs crackers la connaissent, tu peux supposé qu'il n'a pas envis de coopérer à un embargo, etc.
Si un cracker la connait, tu peux supposé qu'elle est public (il peut la rendre public du jour au lendemain), que l'embargo à fourré, etc.
Si un cracker la connait (donc l'utilise), il faut prévenir les utilisateurs (désactiver sshd, réajuster les fichiers de configuration, etc). Prévenir les utilisateurs empêche tout embargo, donc la faille est public.
etc.
Mais c'est trop compliqué pour vous de réfléchir donc j'arrête ici.-
[^]Re: Mise en perspective
Posté par Yusei () le 15/05/2008 à 21:03. (lien). Évalué à 8.Tu es dégoulinant de condescendance, comme d'habitude, mais en supposant que tu t'intéresses quand même à la discution, je me permettrai de souligner que:
- un cracker peut très bien décider d'exploiter une faille avant de la rendre publique, puisque la rendre publique revient à aider les gens à la faire disparaître
- il est difficile pour les mainteneurs de savoir si un cracker connait et exploite une faille. On ne peut donc pas raisonner en se disant "tant que je ne divulgue pas une faille, personne ne peut l'exploiter".-
[+] [^]Re: Mise en perspective
Posté par IsNotGood () le 15/05/2008 à 21:19. (lien). Évalué à -2.Très bien, exprique au trou du cul de prétentieux que je suis, ce qu'on doit faire ?
Ou du moins, ce qui devrait être fait et n'est pas fait.
Parce que les "je coupe les cheveux en quatre pour casser un raisonnement", ça me brise les couilles.-
[^]Re: Mise en perspective
Posté par wismerhill (page perso, ) le 15/05/2008 à 21:28. (lien). Évalué à 2.Personne ici n'explique ce qu'il faut faire, nos arguments sont justement qu'il n'y a pas une bonne façon de faire mais qu'il faut réfléchir à la meilleure chose à faire au cas par cas suivant la faille en question.
(but you can leave your hat on)-
[^]Re: Mise en perspective
Posté par IsNotGood () le 15/05/2008 à 21:40. (lien). Évalué à 2.Je dis ce qui se fait en général, d'autres disent "ça dépend".
Très intéressant.
Et si tu laissais les "experts" avoir un avis en premier ?
Je suis neuneu quand ça touche à la sécurité.
Quand je trouve ce que je crois être un trou de sécurité, j'en informe les experts en privé. Je ne vais pas inventer dans mon coin ce que je crois être la meilleur solution pour gérer le problème.
Et toi ?-
[^]Re: Mise en perspective
Posté par wismerhill (page perso, ) le 15/05/2008 à 21:44. (lien). Évalué à 2.Je réfléchis.
Si je trouve une grosse faille dans wuftpd (ok, l'exemple est facile), je vais surement en informer les développeurs, mais je vais aussi prévenir les gens que je connais de ne pas utiliser ça parce qu'il y a une faille dedans (pas besoin de dire laquelle).
-
-
-
[^]Re: Mise en perspective
Posté par Yusei () le 15/05/2008 à 21:42. (lien). Évalué à 4.Amusant que tu te vexes pour "condescendant" après avoir expliqué qu'on était trop bête pour réfléchir.
-
[^]Re: Mise en perspective
Posté par fredix (Jabber id, page perso, ) le 15/05/2008 à 22:07. (lien). Évalué à 3.il a du le lire en 2 mots :)
-
-
-
-
-
-
-
-
-
-
[^]Re: Mise en perspéctive
Posté par Gniarf () le 15/05/2008 à 17:50. (lien). Évalué à 2.faut arreter de fumer la moquette, les enfants.
en l'occurrence je ne fais preuve d'aucun coup de gueule ni rien. vraiment. c'est pas que je m'en fous mais j'ai pas encore tout compris.
je n'ai pas compris toutes les implications de cette gaffe. et je peux vous affirmer que des experts reconnus de boites de sécus très sérieuses et largement à la pointe de ce domaine n'ont pas encore tout compris non plus.--
Windows has no users. It has hostages.-
[^]Re: Mise en perspéctive
Posté par Geoffroy Carrier (Jabber id, page perso, ) le 18/05/2008 à 03:46. (lien). Évalué à 2.Les implications elles sont connues. En gros le générateur mal seedé fait qu'il n'y a plus que 65000 clefs différentes (selon ton architecture quand même), donc que l'oracle est beaucoup plus forte que voulu. Après, on ne sait dans quelle mesure la brute force pourra être aidée de l'intelligence, mais on ne l'a jamais su dans la configuration précédente (avec beaucoup plus de clefs possibles). En tous cas, ça me conforte dans l'idée qu'il vaut éviter de patcher quand les mecs upstream savent beaucoup mieux que toi ce qu'il font.
-
-
-
-
[^]Re: Mise en perspéctive
Posté par bubar () le 15/05/2008 à 17:38. (lien). Évalué à 3.Tu t' emballes mon ami.
Ce n' est pas parceque tu ne remontes pas la faille aux concernés directement, que tu es "un con". Même un non expert peut voir qu' il y a d' autres moyens d' être utile à la correction de la faille que la remontée directe upstream.
(d' ailleurs, ce n' est pas une des raisons du traitement à part, non public, dans le bugzilla de redhat ? laisser le temps de la correction, mais aussi se laisser le temps de choisir... ). Premier point. non ?
Dans l' autre registre, l' attitude full disclosure se tiens aussi :
En rendant publique des "o days" ou quasi, on force à la correction.
Les manières peuvent être diverses.
non ?-
[^]Re: Mise en perspéctive
Posté par IsNotGood () le 15/05/2008 à 17:57. (lien). Évalué à 2.> d' ailleurs, ce n' est pas une des raisons du traitement à part, non public, dans le bugzilla de redhat ?
Lorsque tu fais un rapport de bug sur une faille de sécurité, il est proposé de mettre le bug en confidentiel. Tu accèptes ou non. Si tu n'accèptes pas de le mettre en confidentiel, il reste public (Red Hat n'y touche pas, il reste public).
Le bugzilla de Red Hat a aussi des rapports de bug de ses clients (via la hot line typiquement). Pour ses rapports de bug, la confidentialité est appliquée. Un client de Red Hat est libre d'utiliser directement http://bugzilla.redhat.com/ et de mettre le rapport de bug en public.
Les rapports de bug de sécurité sous "embargo" en sont pas publics jusqu'à la fin de l'"embargo". À la fin de l'embargo (ou si le bug a été publié), ils sont public.
-
[^]Re: Mise en perspéctive
Posté par IsNotGood () le 15/05/2008 à 18:01. (lien). Évalué à 3.> En rendant publique des "o days" ou quasi, on force à la correction.
Non. Tu mets seulement un vent de panique (chez les développeurs et les utilisateurs).-
[^]Re: Mise en perspéctive
Posté par wismerhill (page perso, ) le 15/05/2008 à 19:17. (lien). Évalué à 2.Ça dépend des cas, parfois il y a un workaround simple pour éviter la faille en attendant une vraie correction.
Par exemple pour un serveur ftp (qui est une faille en lui-même), tu peux tout simplement le couper, en installant éventuellement un autre si le service est critique.
Pour une faille du sous-système sftp de openssh tu pourrais simplement désactiver celui-ci le temps de la correction, scp (et fish) est toujours là pour les transferts de fichiers.
Il y a probablement beaucoup d'autres exemples où quelques mesures simples peuvent rendre une faille de sécurité sans gravité en attendant une vraie solution.-
[^]Re: Mise en perspéctive
Posté par IsNotGood () le 15/05/2008 à 19:49. (lien). Évalué à 3.Mouaif.
L'"embargo" est quelque chose pris très au sérieux. On peut trouver plein de rapports de bug de sécurité sur http://bugzilla.redhat.com/ ou le correctif est trouvé avant la fin de l'embargo. Et bien Red Hat attend la fin de l'embargo pour diffuser le correctif. C'est être "urbain" avec les autres utilisateurs/distributions.
Tant qu'on peut tenir l'embargo, ça donne du temps pour paufiner le correctif, ça donne du temps aux autres distributions, etc.
C'est quelque chose de très important. Et ce n'est pas obligatoire ! Ce n'est pas à confondre avec de la censure par exemple.
Enfin, on en voit pas des embargos se prolonger sans justification.
-
[^]Re: Mise en perspéctive
Posté par pasBill pasGates () le 15/05/2008 à 23:10. (lien). Évalué à 9.Par exemple pour un serveur ftp (qui est une faille en lui-même), tu peux tout simplement le couper, en installant éventuellement un autre si le service est critique.
C'est faire preuve d'une meconnaissance totale du fonctionnement d'une entreprise que de suggerer qqe chose de ce genre.
Meme avec un workaround, les societes mettent un temps non negligeable a l'implementer, car elles doivent le tester.
La realite, et elle est partagee par a peu pres tous les gens concernes, c'est qu'un zero day c'est Mal(TM) pour l'editeur, et pour les clients.
Pour etre tres tres simple, il n'y a aucune raison valide pour sortir publiquement un zero day. Si t'as pas confiance dans l'editeur, tu lui donnes X jours et tu fais ton annonce automatiquement apres le delai, methode tres simple, que bcp de gens utilisent.-
[^]Re: Mise en perspéctive
Posté par Sébastien FRADE (Jabber id, ) le 17/05/2008 à 13:26. (lien). Évalué à 1.Je suis d'accord avec IsNotGood et PasBill PasGates, il faudrait penser au fait qu'annoncer publiquement dès le zéro day n'apporte rien d'autre qu'une augmentation du danger si l'éditeur s'occupe généralement de règler les failles.
En annonçant publiquement, on ne fait que donner des idées à des crackers supplémentaires.
En ne rendant pas public directement, on laisse à l'éditeur un laps de temps pour corriger la faille et ainsi éviter des dangers de grande ampleur. C'est simplement de la logique, du bon sens.-
[^]Re: Mise en perspéctive
Posté par Gniarf () le 17/05/2008 à 15:50. (lien). Évalué à 4.ça c'est quand l'éditeur dit qu'il va la corriger et qu'il a un certain nombre de corrections effectuées à son actif, donc en gros que tu peux le croire.
parce que dans la vraie vie, c'est pas toujours ça.
par exemple la politique d'autres éditeurs c'est de ne rien corriger et de te menacer d'un procès monstrueux si tu mouftes. pour les plus gentils. j'ai besoin de dire que d'autres sont liés à des intérêts douteux voir mafieux ?
oh toi tu peux te dire je m'en fous, je me suis aperçu du problème, je n'ai plus qu'à oublier ce produit et l'affaire est close.
sauf qu'en général tu n'es pas seul au monde et tu t'aperçois avec effroi que tes collègues, amis, famille etc utilisent le même logiciel, troué et activement exploité par des vilains de Russie ou de Roumanie tout ça tout ça qui se promènent sur leurs disques durs comme s'ils étaient chez eux.
tu fais quoi, là ?--
Windows has no users. It has hostages.-
[^]Re: Mise en perspéctive
Posté par IsNotGood () le 17/05/2008 à 18:08. (lien). Évalué à 1.> par exemple la politique d'autres éditeurs c'est de ne rien corriger et de te menacer d'un procès monstrueux si tu mouftes.
Arrête le délire, on n'a jamais vu ça dans le libre.-
[^]Re: Mise en perspéctive
Posté par Gniarf () le 17/05/2008 à 20:50. (lien). Évalué à 2.euh toto, si tu savais lire, tu aurais remarqué qu'on parle depuis quelques posts de politique de disclosure en général et que ça n'a plus rien à voir avec le fait qu'un soft est libre ou pas.
(et en passant, Adobe, Oracle ou Skype (enfin, eBay) sont des boites qui font des produits sous *nix. des produits très populaires. des produits souvent troués)--
Windows has no users. It has hostages.-
[^]Re: Mise en perspéctive
Posté par IsNotGood () le 17/05/2008 à 21:34. (lien). Évalué à 2.Tu réponds à un commentaire :
- "il faudrait penser au fait qu'annoncer publiquement dès le zéro day n'apporte rien d'autre qu'une augmentation du danger si l'éditeur s'occupe généralement de règler les failles."
Puis toi :
- "ça c'est quand l'éditeur dit qu'il va la corriger"
Si la faille n'est pas public, il ne dit qu'il va la corriger. Par définition, ce n'est pas public.
> parce que dans la vraie vie, c'est pas toujours ça.
C'est par rapport à quoi ?
Par rapport au commentaire auquel tu réponds ?
Le cas des éditeurs qui ne s'occupent pas de règler les failles, le commentaire auquel tu réponds n'en parle pas.
Tu changes de sujet, voire les mélange, alors forcément on peut se prendre les pieds dans le tapis.
"La vraie vie" ne se résume à généraliser la caricature que tu as faite.
La vraie vie c'est aussi plein d'éditeur qui font correctement leur boulot.-
[^]Re: Mise en perspéctive
Posté par Gniarf () le 17/05/2008 à 22:30. (lien). Évalué à 3.> si la faille n'est pas public, il ne dit qu'il va la corriger. Par définition, ce n'est pas public.
ben si. quand l'éditeur répond à la personne qui lui a indiqué la faille.
des fois cette personne met des gens biens (tm) en copie, histoire de garder une trace, un historique, revenir à la charge si il n'y a aucune demande de précision, ou si l'éditeur fait le mort pendant 2 semaines puis 2 mois puis 6...
> La vraie vie c'est aussi plein d'éditeur qui font correctement leur boulot.
et que pleins d'autres ne le font pas ou alors en se faisant vraiment tirer l'oreille, car au final ça leur coute des sous, du temps, ça leur fait de la mauvaise publicité, etc etc
allez, zou, retourne dans ta cave, y'a mémé qui veut sortir du congélo.--
Windows has no users. It has hostages.-
[^]Re: Mise en perspéctive
Posté par Sébastien FRADE (Jabber id, ) le 18/05/2008 à 00:50. (lien). Évalué à 0.Désolé de dire ça, mais la paranoïa maladive, ça se soigne.
Ce n'est pas parce qu'il existe des éditeurs avec des politiques douteuses, mais faut pas tout mélanger. Autant je n'adhère pas à la politique éditoriale de certains éditeurs, autant la grande majorité des éditeurs font leur boulot correctement.
Si tu n'as pas confiance en un éditeur, rien ne t'empêche de changer d'éditeur, sans forcément rentrer dans un rapport de force stupide. Parce que c'est bien ça le soucis: en balançant la faille publiquement, tu prends en otage l'éditeur ainsi que tous les utilisateurs de façon à "accélérer la réaction du dit éditeur". Hors, il faut bien se rendre compte que dans mon post, je partais de l'hypothèse que tu étais assez malin pour choisir d'utiliser des logiciels provenant d'éditeurs en qui tu as confiance (désolé, je n'ai pas forcément envie de me mettre à la place des masochistes qui choisissent d'utiliser des logiciels d'éditeurs en qui ils n'ont pas confiances). Dans ce cas, désolé mais ne pas laisser à l'éditeur un temps de recul est stupide parce que tu rends encore plus dangereuse la faille durant le laps de temps entre l'annonce publique et la correction (qui prend un temps certain en raison de la nécessité de ne pas balancer un patch à l'arrache).
Après, si tu ressens constamment le besoin d'un rapport de force avec l'éditeur pour croire que tu défends tes droits, tu as sûrement à te questionner sur ta façon d'appréhender la "vraie vie".
Personnellement, j'utilise Mandriva, et je fais confiance à l'éditeur. Dans ce cas, si je trouve une faille critique, je la renvoie à Mandriva, mais en privé, pour leur laisser le temps de régler le soucis sans mettre en danger tout le monde (surtout dans le cas d'un truc aussi sensible qu'OpenSSL).
Arrète d'être irrespectueux vis-à-vis de IsNotGood, il ne fait qu'expliquer son point de vue. Faudrait redescendre un peu de ton piédestal. Le fait d'agresser constemment comme tu le fais montre une certaine frustration qu'il te faudrait résoudre.
Dans la "Vraie Vie", les gens vivent en société et cherchent à collaborer autant que possible. Et un éditeur qui se respecte (et il y en a une majorité) cherche avant tout à conserver ses clients ; donc à ne pas les laisser dans une merde noire.-
[^]Re: Mise en perspéctive
Posté par Gniarf () le 18/05/2008 à 02:35. (lien). Évalué à 3.> Désolé de dire ça, mais la paranoïa maladive, ça se soigne.
et qu'attends-tu donc pour te soigner ?
> la grande majorité des éditeurs font leur boulot correctement.
farpaitement, je n'ai jamais dit le contraire. et c'est indirectement parce que les autres se cachent ou ne sont pas vraiment considérés comme des éditeurs.
> en balançant la faille publiquement, tu prends en otage l'éditeur ainsi que tous les utilisateurs de façon à "accélérer la réaction du dit éditeur".
oh je te rassure, il y a des gros malins qui font ça alors même qu'ils n'utilisent pas ledit logiciel ou ne seront pas impactés. oui, ils sont cruels. c'est ça aussi, la Vraie Vie, il y a des salauds et des méchants. la méchanceté gratuite a quelque chose de jouissif. oui, ça se soigne. en général ils ne veulent pas.
j'ai eu une découverte récente de faille à mon actif et j'estime avoir fait les choses correctement et accessoirement proprement. je n'ai d'ailleurs pas utilisé le soft en question (un jeu) puisqu'il fallait s'inscrire et que c'était la procédure d'inscription qui était trouée... la flemme de m'inscrire ensuite
> Dans la "Vraie Vie", les gens vivent en société et cherchent à collaborer autant que possible. Et un éditeur qui se respecte (et il y en a une majorité) cherche avant tout à conserver ses clients ; donc à ne pas les laisser dans une merde noire.
je crains que ton expérience de la Vraie Vie se cantonne encore à un monde plein de poneys roses avec une crinière argentée et une étoile sur le derrière. il y a d'autres sociétés hors de notre petit cocon franco-européen de l'ouest. d'autres mentalités et d'autres systèmes de valeurs. limite d'autres civilisations. ailleurs on cherche surtout à t'exploiter, toi ou ta machine (enfin sa connexion internet à haut débit), et tant mieux si tu es loin, dans un autre pays. un peu comme Elf exploite les locaux en Birmanie, tu vois : ils comptent pour moins que rien.
agir de façon responsable (ce que tu sous-entends par 'vivre en société') n'est pas une loi de la nature ou une constante universelle. en fait c'est même limite contre-nature : à bien y réfléchir, tu peux gèner tes concurrents qui ont le même fournisseur que toi...
(sinon, faut arrêter d'être tout le temps désolé, ça se soigne aussi)--
Windows has no users. It has hostages.-
[^]Re: Mise en perspéctive
Posté par Sébastien FRADE (Jabber id, ) le 20/05/2008 à 20:50. (lien). Évalué à 1.[quote]et qu'attends-tu donc pour te soigner ?[/quote]
Je préfère te laisser la première place, tu sembles en avoir plus besoin que moi.
[quote]farpaitement, je n'ai jamais dit le contraire. et c'est indirectement parce que les autres se cachent ou ne sont pas vraiment considérés comme des éditeurs.[/quote]
Ah non? Toi, quand tu penses à un éditeur, tu pars de ce principe:
[quote]ça c'est quand l'éditeur dit qu'il va la corriger et qu'il a un certain nombre de corrections effectuées à son actif, donc en gros que tu peux le croire.
parce que dans la vraie vie, c'est pas toujours ça.
par exemple la politique d'autres éditeurs c'est de ne rien corriger et de te menacer d'un procès monstrueux si tu mouftes. pour les plus gentils. j'ai besoin de dire que d'autres sont liés à des intérêts douteux voir mafieux ?[/quote]
Moi par contre, je te dis qu'il faut choisir un éditeur en qui tu as confiance et ainsi pouvoir conserver le temps de latence pendant lequel la faille n'est pas rendue publique pour éviter justement l'exemple suivant que tu as décrit:
[quote]u n'es pas seul au monde et tu t'aperçois avec effroi que tes collègues, amis, famille etc utilisent le même logiciel, troué et activement exploité par des vilains de Russie ou de Roumanie tout ça tout ça qui se promènent sur leurs disques durs comme s'ils étaient chez eux.[/quote]
D'ailleurs, au passage, tu peux aussi avoir des français, des américains, des anglais, des tout ce que tu veux dans ton ordinateur à partir du moment où la faille est rendue publique sans correction immédiate. D'où l'intérêt de se réserver ce fameux temps de latence.
[quote]tu fais quoi, là ?[/quote]
Je n'agrave pas la situation et fait confiance à ceux qui sont mieux placés que moi pour agir. Le mainteneur n'avait pas à modifier ce fichu paquet sans savoir ce qu'il faisait, il n'aurait jamais dû être seul sur un élément critique, et il y aurait dû avoir vérification. Mais surtout, je ne m'amuse pas à annoncer publiquement que ce type de faille existe pour "accélérer le mouvement". Parce que je n'évolue pas contre les éditeurs, mais bien en collaborant avec les gens dont j'ai choisi les services. Ou alors, si je ressents que je ne peux pas avoir une protection rapide pour mes données sans rentrer dans un rapport de force avec l'éditeur, je change d'éditeur.
-
-
[^]Re: Mise en perspéctive
Posté par IsNotGood () le 18/05/2008 à 02:43. (lien). Évalué à 4.> Dans ce cas, si je trouve une faille critique, je la renvoie à Mandriva, mais en privé, pour leur laisser le temps de régler le soucis sans mettre en danger tout le monde
Notons aussi que les distributions, lorsqu'il y a une faille de sécurité, informent cert-vendor. Donc toutes les distributions sont au courant (en privé) si c'est un problème upstream. Elles sont toutes dans le même bateau si tu envoyes le rapport de bug à "seulement" Mandriva. Ce rapport de bug, même qu'à une distribution, est suffisant et apprécié de tous.
Je trouve ceci vraiment excellent (mais c'est aussi le moindre) de voir que les distributions ne se tirent pas dans les pattes lorsqu'il sagit de sécurité.-
[^]Re: Mise en perspéctive
Posté par Sébastien FRADE (Jabber id, ) le 20/05/2008 à 20:56. (lien). Évalué à 0.Merci de la précision. Même si je m'en doutais fortement, c'est toujours intéressant à savoir.
En effet c'est le moindre.
-
-
[^]Re: Mise en perspéctive
Posté par briaeros007 () le 18/05/2008 à 13:35. (lien). Évalué à 6.
Désolé de dire ça, mais la paranoïa maladive, ça se soigne.
Désolé de dire ça, mais en sécurité informatique, il FAUT être paranoiaque.
Tiens exemple con : le pentagone cherche a virer TOUS les équipement réseau dont leur puce n'ont pas été concu et produit aux US.
Pourquoi ? Pour éviter une backdoor matérielle (presque)impossible à déceler.
Pour toi c'est de la paranoia maladive, pour les autres, c'est appliqué des normes de sécurité.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Mise en perspéctive
Posté par IsNotGood () le 18/05/2008 à 15:53. (lien). Évalué à 1.> Désolé de dire ça, mais en sécurité informatique, il FAUT être paranoiaque.
Et c'est toi qui le dit...
Ben Debian ne devrait pas être autorisé n'importe qui à patcher OpenSSL...
Il ne faut pas utiliser Debian/Ubuntu/etc.
Debian ne devrait pas utiliser Debian.
Etc.
Faire de la paranoïa la règle absolue est stupide et contre productif.
Il est d'autant plus marrant que tu dises "il FAUT être paranoiaque" alors que manifestement Debian ne l'a pas été et que tu n'arrêtes de chercher des excuses au mainteneur qui a fait la boulette alors qu'il ne l'a pas été non plus (et que tu ne trouves pas ça grave...).-
[^]Re: Mise en perspéctive
Posté par briaeros007 () le 18/05/2008 à 20:20. (lien). Évalué à 2.Et c'est toi qui le dit...
Oui c'est moi, et ca fait quoi si c'est moi qui le dis ?
Ah rien ... vu que j'ai reconnu que debian avait fait des bourdes, et j'ai aussi reconnu que si je voulais une garantie, j'aurais pris de la maintenance (avec contraintes financières) ...
Il ne faut pas utiliser Debian/Ubuntu/etc.
Si on veut être rigoureux et extrême,dans le etc il y a tout logiciels que tu n'a pas auditer, donc toutes les distribs a peu de choses près, donc fedora et redhat.
Ah tiens y'a pas que tes deux ennemis jurer (a t'en entendre parler).
Faire de la paranoïa la règle absolue est stupide et contre productif.
J'ai dis que c'était la règle absolue ?
j'ai dis qu'il le fallait.
Il la faut car il faut avoir à l'esprit les risques possibles et existants! Elle sert à ça la parano!
Par contre, Je n'ai pas dis qu'il ne fallait pas aussi savoir faire la part des choses.
Encore une supposition de ta part (un homme de paille).
Si quelqu'un utilise une règle qui peut sembler paranoiaque, et que c'est dans le cadre de la sécurité, alors cette règle lui convient tout a fait. Il n'y a pas de paranoia en sécurité, mais une prise de risque, qui doit etre fait en connaissance de cause (d'ou le "il faut etre paranoiaque").
Et vouloir faire croire le contraire est, excuse moi mais je n'ai pas d'autres mots, complètement idiot.
que tu n'arrêtes de chercher des excuses au mainteneur qui a fait la boulette alors qu'il ne l'a pas été non plus (et que tu ne trouves pas ça grave...).
Une phrase, deux affirmations, toutes les deux fausses.
Alors je t'apprendrais à lire, parce que je l'ai déja dis plusieurs fois clairement : je reconnais tout a fait que le mainteneur de debian a fait des erreurs.
Je reconnais aussi qu'il y a eu d'autres choses que juste "c'est la faute a une seule personne" dans cette affaire.
Contrairement a toi je ne suis pas obnubilé par le binaire. (suffit de voir le début de mon post d'ailleurs...)
Enfin je n'ai jamais dis que je ne trouvais pas ça grave. Si tu as compris ca d'une de mes phrases, j'ai du mal m'exprimer
bref, attaquons, attaquons, il en restera toujours quelquechose...--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Mise en perspéctive
Posté par boklm (page perso, ) le 19/05/2008 à 01:17. (lien). Évalué à 4.Par contre, Je n'ai pas dis qu'il ne fallait pas aussi savoir faire la part des choses.
Justement, la parano, ca ne veut pas dire ne pas bien faire la part des choses ?
-
[^]Re: Mise en perspéctive
Posté par IsNotGood () le 19/05/2008 à 02:45. (lien). Évalué à 2.> Si on veut être rigoureux et extrême,dans le etc il y a tout logiciels que tu n'a pas auditer, donc toutes les distribs a peu de choses près, donc fedora et redhat.
Ben oui.
> Ah tiens y'a pas que tes deux ennemis jurer (a t'en entendre parler).
Je suis cohérent. Je ne dis pas qu'il FAUT être paranoïaque (donc je peux utiliser une Fedora, voire même une Debian si le risque me parait raisonnable). Toi tu dis qu'il FAUT être paranoïaque. Ben utilise rien.
> Il n'y a pas de paranoia en sécurité, mais une prise de risque, qui doit etre fait en connaissance de cause
C'est très différent de "il FAUT être paranoïaque". La prise de risque n'est pas le truc des paranos (t'avais remarqué ça ?).
> qui doit etre fait en connaissance de cause
Dans le cas de la sécurité, ce n'est pas vraiment ça.
Si je suis cascadeur, je vais prendre des risques. Je dois les faire en connaissance de cause. Je vais par exemple prendre plus de risque de d'habitude pour faire une belle cascade. Mais prendre des risques pour la sécurité n'est pas logique. Par contre même si je suis cascadeur, je peux avoir un conseillé sécurité qui va me dire de mettre un casque. Ce n'est pas le conseillé sécurité qui prend les risques, c'est moi. C'est moi qui doit être conscient des risques.
Pour la sécurité, je dois analyser les risques et faire pour en prendre le moins possible pour un contexte donné (par exemple ça ne veut pas dire qu'il faut annuler la belle cascade dangereuse, mais la rendre moins dangereuse).
> Et vouloir faire croire le contraire est, excuse moi mais je n'ai pas d'autres mots, complètement idiot.
Soit pas "idiot", reste parano, débranche toi d'Internet alors.
> Une phrase, deux affirmations, toutes les deux fausses.
OK, je m'excuse.
Mais au début, tes propos ce n'étaient pas vraiment ça...-
[^]Re: Mise en perspéctive
Posté par briaeros007 () le 19/05/2008 à 11:41. (lien). Évalué à 0.Mais prendre des risques pour la sécurité n'est pas logique.
Ah bon, tu as concu ton propre réseau séparé par des tunnels optiques avec des protections quantiques sur des os EAL7?
Non ?
Ben alors tu as pris des risques.
Ce n'est pas le conseillé sécurité qui prend les risques, c'est moi. C'est moi qui doit être conscient des risques.
Et quand tu es sysadmin d'un parc, tu es a la fois conseiller en sécurité, et cascadeur.
Pour la sécurité, je dois analyser les risques et faire pour en prendre le moins possible pour un contexte donné
Et juste avant tu disais :
Mais prendre des risques pour la sécurité n'est pas logique.
Ou comment dire tout et son contraire dans le meme post...--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Mise en perspéctive
Posté par IsNotGood () le 19/05/2008 à 18:54. (lien). Évalué à 3.Tu tombes mal, j'ai bossé dans la sécurité (pas la sécurité informatique). En fait, plus la qualité, mais il y a plein de points communs.
J'ai bien essayé de faire passer qu'il y a le responsable sécurité (ou l'expert sécurité) et le client. Tu n'as pas voulu remarquer la chose.
L'expert sécurité ne prend pas de risque. Si le client lui commande un treuil qui doit supporter 10 tonnes dans un environnement définit, le treuil doit supporter 10 tonnes et pas 9 car l'expert sécurité on a voulu faire des économies. Le responsable sécurité n'a pas à prendre de risque. S'il le fait, c'est une faute grave.
Le client peut prendre des risques (NB: on ne recommande évidemment pas qu'il en prenne). C'est au client d'avoir conscience des risques et de définir le niveau de sécurité qu'il veut. Si le client veut accrocher des poids de 12 tonnes à son treuil alors qu'il a commandé un treuil de 10 tonnes, c'est lui qui prend les risques, c'est lui qui est responsable s'il y a une catastrophe.
> Ah bon, tu as concu ton propre réseau séparé par des tunnels optiques avec des protections quantiques sur des os EAL7?
Non. Et alors ?
L'évaluation des risques tu la fais tout le temps.
Si tu demandes un risque proche de 0 à un expert sécurité automobile, il va proposer de brider les voitures à 10 km/h maxi. Mais le client (l'état, les citoyens) accèpte de prendre le risque de rouler à 130 km/h, accèpte d'avoir 5000 morts par an. L'expert n'a pas à prendre de risque ni les définir (il peut évidemment les évaluer). Le client peut en prendre (je répète encore...).
Pour un mirroir public, le client va dire, pour faire court, qu'il s'en fout des risques, et l'expert va proposer le minimum.
Ce n'est pas à l'expert de définir le risque à prendre ! Sinon on tombe dans la stupidité où l'expert se donne du boulot.
Le mainteneur d'OpenSSL est un expert sécurité (ou devrait l'être).
Le cas du développement d'un logiciel de sécurité (donc avec des bugs) n'est pas une prise de risque des experts. Ils doivent donner le niveau de sécurité (si c'est un logiciel beta, alors ça sera faible). C'est l'utilisateur, informé par l'expert, qui prendra le risque d'utiliser un logiciel en phase beta.
> Ben alors tu as pris des risques.
En tant que client/utilisateur oui. Mais ces mes oignons, c'est ma responsabilité.
Tu viens sur internet, tu prends des risques, c'est tes oignons.
> Ou comment dire tout et son contraire dans le meme post...
Et toi l'art de faire l'autruche.-
[^]Re: Mise en perspéctive
Posté par briaeros007 () le 19/05/2008 à 20:30. (lien). Évalué à 1.L'expert sécurité ne prend pas de risque. Si le client lui commande un treuil qui doit supporter 10 tonnes dans un environnement définit, le treuil doit supporter 10 tonnes et pas 9 car l'expert sécurité on a voulu faire des économies. Le responsable sécurité n'a pas à prendre de risque. S'il le fait, c'est une faute grave.
C'est bien ça, sur les grosses boites ou tu peux dissocier les deux fonctions.
Sur la pratique (la majorité amha des pme, tpe, et autre), ben le sysadmin il est à la fois conseiller en sécurité, et à la fois client.
Et il fait avec les différentes contraintes qu'il a (cout, sécurité, délai, ...)
Le client peut en prendre (je répète encore...).
Sauf que tu repars sur une optique ou les deux fonctions sont complètement dissocié, ou, dans le cadre de la sécu informatique, c'est relativement rare.
Pourquoi les gens font de la sécurité ? Pas pour se faire payer en tant que consultant (enfin certain si, mais pas la majorité de ceux qui la font), mais parce qu'ils doivent assurer la sécurité du systeme dont ils ont la charge.
Si ils ont la charge du systeme, ils ont aussi l'ensemble des contraintes qui s'y applique.
Enfin, ton aspect binaire est bien beau, mais oublie un point TRES important.
Le but d'un conseiller, ce n'est PAS de conseiller des trucs "trop top génial" en théorie mais innaplicable.
Ca en info, TOUT LE MONDE SAIT LE FAIRE : ON ETEIND LE PC !
Le but d'un conseiller est de proposer la MEILLEURE APPROCHE EN TENANT COMPTE DES CONTRAINTES.
Le cas du développement d'un logiciel de sécurité (donc avec des bugs) n'est pas une prise de risque des experts. Ils doivent donner le niveau de sécurité (si c'est un logiciel beta, alors ça sera faible). C'est l'utilisateur, informé par l'expert, qui prendra le risque d'utiliser un logiciel en phase beta.
Si tu souhaite le voir comme ça, c'est ton choix.
Mais ca tombe bien que tu le vois comme ça , regarde bien les licences BSD et GPL des logiciels utilisé.
L'UTILISATEUR FINAL SAVAIT QU'IL N'AVAIT AUCUNE GARANTIE.
(spécifié dans la licence).
Si tu veux un truc en sécu tel que tu le décris, tu demande une certif (EAL, FIPS, ...), et tu prend certainement pas un truc concu par un parfait incconu.
En tant que client/utilisateur oui. Mais ces mes oignons, c'est ma responsabilité.
Tu viens sur internet, tu prends des risques, c'est tes oignons.
On es donc d'accord, le mainteneur avait rien a dire : le client était conscient des risques en prenant un soft GPL/BSD/...
> Ou comment dire tout et son contraire dans le meme post...
Et toi l'art de faire l'autruche.
Je vois pas ou pointer tes contradictions c'est faire l'autruche, mais ca doit etre ta fameuse logique--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
-
-
-
[^]Re: Mise en perspéctive
Posté par Sébastien FRADE (Jabber id, ) le 20/05/2008 à 20:33. (lien). Évalué à 3.Non, dans la réalité, il faut être PRAGMATIQUE. Tu dois mesurer les dangers potentiels et agir intelligemment.
Par exemple, on ne patch pas à la légère un logiciel critique. On ne rend pas publique une faille quand on peu gagner un peu de temps sans que trop de monde soit au courant et ne représente un danger.
Et non, pour moi, ce qu'à décidé le Pentagone n'est pas de la paranoïa maladive, puisque je trouve celà logique pour un service comme celui-là. Par contre je trouve extrêmement paranoïaque de partir du principe que l'éditeur de logiciels que tu as choisis ne corrigera pas la faille sauf si tu le mets en porte-à-faux.
Le coté paranoïaque maladif, c'est de céder à la panique en hurlant à la fin du monde pour déclencher une panique générale et augmenter la dangerosité de la faille en la rendant publique, pas d'être pragmatique en se prémunissant au maximum des risques.
-
-
-
-
-
-
-
[^]Re: Mise en perspéctive
Posté par Sébastien FRADE (Jabber id, ) le 18/05/2008 à 00:55. (lien). Évalué à 2.Tu lis jusqu'au bout les posts ou tu ne lis que ce qui t'intéresse?
Faudrait comprendre que je ne prends pas le cas d'un éditeur qui ne veut pas corriger, mais bien un éditeur en qui tu peux avoir confiance.
Si tu n'as pas confiance en un éditeur de logiciels libres, rien ne t'empèche de passer à un autre éditeur de logiciels libres.
Et arrète d'associer tout et n'importe quoi, à la fin.
-
-
-
-
-
-
[^]Re: Mise en perspéctive
Posté par Thomas (Jabber id, page perso, ) le 17/05/2008 à 12:28. (lien). Évalué à 1.> En rendant publique des "o days" ou quasi, on force à la correction.
Pour info le "o days" date d'un mois ou presque.
-
-
-
-
-
-
[^]Re: Mise en perspéctive
Posté par F C () le 15/05/2008 à 16:57. (lien). Évalué à 4.Scandaleux je n'irais pas jusque là.
Pour moi cette mésaventure montre les forces et les faiblesses du modèle de développement choisi, tout comme le propriétaire possède les siens.
Il est effectivement, sur certains projets, difficile de trouver des contributeurs, alors des contributeurs compétents....
C'est sûr, ca tombe mal, il y en a des centaines moins critiques, mais saluons la réactivité du libre.
Bref, tout ca pour dire que le terme 'scandaleux' me semble un peu dur :)--
Salut, tu browses à combien, toi ?-
[^]Re: Mise en perspéctive
Posté par thedidouille () le 15/05/2008 à 17:22. (lien). Évalué à 6.Honnêtement, c'est difficile d'imaginer une bourde plus grosse que celle-ci et ayant un impacte plus important.
Sur un paquet aussi critique qu'OpenSSL, les mainteneurs ne devraient pas modifier le code d'origine, à moins de savoir vraiment ce qu'ils font, ça n'a rien à voir avec le modèle ou le nombre de contributeurs.
Le terme "scandaleux" me semble totalement approprié, je vois mal ce qui pourrait plus décridibiliser le libre que ça, on aurait tous préférer que ça n'arrive qu'a une petite distrib, pas utilisée pour héberger des services critiques et ignorée des entreprises.
-
[^]Re: Mise en perspéctive
Posté par H_francis () le 15/05/2008 à 20:20. (lien). Évalué à 2.* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
* OF THE POSSIBILITY OF SUCH DAMAGE.
C'est pas ça le logiciel libre ?-
[^]Re: Mise en perspéctive
Posté par Tanguy Ortolo (page perso, ) le 16/05/2008 à 00:28. (lien). Évalué à 5.Mouraf, si ça se limitait au logiciel libre, ce genre de truc…
-
-
-
[^]Re: Mise en perspéctive
Posté par lejocelyn () le 15/05/2008 à 17:34. (lien). Évalué à 7.J'aimerais bien que tu me cites une ou deux failles parmi les "tonnes" non publiées qui inpactent aussi dangereusement la sécurité et la confidentialités des échanges sur Internet et dans les entreprises !
Ah, un lecteur de PCinpact :).
-
-
-
utilisation dowkd.pl
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
-
[^]Re: utilisation dowkd.pl
Posté par lom (page perso, ) le 15/05/2008 à 14:47. (lien). Évalué à 2.ni l'un ni l'autre.
Pour ca il te faut extraires la cle publique de tes cles privees :
ssh-keygen -y -f fichier.key > id_ssl
puis utiliser dowkd.pl sur le fichier id_ssl.
En tout cas, cest comme ca que ca marche pour ssh-vulnkey (installe par la mise a jour des paquest debain), et je crois me souvenir (lien que je ne retrouve plus) que c'est pareil pour dowd.pl.
[+] Limite du développement bénévole
Au risque d'apparaitre iconoclaste, les professionnels utilisant Debian et ses dérivés devraient pourtant savoir que Debian n'en est pas à son premier gros problême de sécurité.
Il n'y a pas si longtemps pendant un mois il n'y avait pas eu de mise à jour de sécurité, car le responsable n'était pas disponible.
Debian étant une distribution communautaire elle est dépendantes des bonnes volontés.
Dans le cas d'openSSL le mainteneur a fait plus par ignorance combiné avec un problème sérieux de communication que par mauvaise volonté une énorme bêtise.
La aussi Debian montre les limites du développement bénévole. Il n'y a visiblement pas la possibilité de mettre plusieurs mainteneurs sur des paquets dits "sensibles"
Les distributions commerciales dérivées de Debian sont encore plus coupables. Ayant plus de moyen surtout celles visant la clientèle professionnelle devraient contrôler les paquets sensibles pour la sécurité. Elles ne l'ont pas fait. J'espère pour elles que cela n'aura pas trop de conséquence sur leur avenir commercial
Pour finir aux tenant de la gratuité : la sécurité peut être libre mais ele n'est pas gratuite….
Slackware depuis 1996


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.