mais je ferais comme ca :
- contacter [l'éditeur|le dev] en lui donnant tous les details (sans faire le pédant) voir une proof of concept
- quand il t'annonce que c'est corrigé ou au bout d'un temps raisonable (genre pas 2h) prévenir l'éditeur que tu va publier
- la publier en l'envoyant à des sites de sécurité (security focus, frsirt...)
- ne jamais diffuser publiquement l'eventuelle proof of concept
Le plus rentable, ça doit être de chercher un groupe de gens prêt à payer pour que tu ne la donne qu'à eux. Une autre possibilité serait de la rendre publique. Là, c'est toi qui paye, car le créateur du soft t'attaquera en justice (ridicule, mais je crois que ça arrive)
Sinon tu peux contacter le créateur du logiciel, pour commencer, lui expliquer, et avec un peu de chance il corrigera vite. Sinon tu transmet aux sites de sécurités.
Et enfin, si c'est un logiciel libre, tu envois un patch ;-) (enfin, si tu as les compétences)
Il y a plusieurs courants en ce qui concerne la publication de faille.
1 - Ceux qui sont pour la publication totale ("grand public" et constructeurs)
2 - Ceux qui n'avertissent que les constructeurs
3 - Ceux qui se gardent les failles pour eux
4 - Ceux qui publient la faille le jou même de la découverte
Bon on part du principe que tu veux rendre service donc on oublie les point 3 et 4.
Le point 1 est le plus utilisé. Il crée pas mal de discussion suite à la publication publique de la faille ainsi que l'exemple démontrant sa faisabilité il y a beaucoup de script kiddies qui piratent des centaines de serveurs. Cependant, il permet la reconnaissance à l'auteur de la découverte. Dans le cas du point 2, il arrive que le constructeur corrige discrétement la faille sans forcèment remercier celui qui a fait la découverte ce qui crée très souvent des problème d'égo...
Bon revenons à nos moutons comme publier la faille...
En gros
1 - tu avertis le fabricant que t'as trouvé un bug et que t'aimerais faire une publication publique
2 - le fabricant te réponds, tu lui donnes les détails techniques sur comment produire la faille (s'il ne répond pas après un certains temps tu publies la faille)
3 - tu lui laisses le temps de patcher ainsi que délai pour que les administrateurs puissent patcher
4 - tu la faille avec ou sans PoF (proof of concept) publies dans les principales listes de sécurités c'est-à-dire (securityfocus, muc.list.bugtraq, vulnwatch, full disclosure,...)
En espérant avoir répondu à ta question :-)
Je trolle dès quand ça parle business, sécurité et sciences sociales
Je pense vraiment pas que ça interesse les scripts kiddies, c'est un cas assez particulier qui permet une élévation de privilège interne sur des matèriels réseaux. On en fait pas un vers quoi ...
Je vais déjà voir avec le constructeur, ce qu'il en pense. Mais ça risque de rester interne à jamais car les matèriels réseaux sont quand même beaucoup moins mis à jour (à tort) que les services mails et autre ...
Le genre de truc qui pourrait permettre de faire des attaques type "man in the middle" assez facilement ? J'y connais pas grand chose en sécurité, mais dit comme ça, ça doit permettre des attaques pas forcément de grandes envergures, mais relativement ciblées pour récupérer des infos sensibles éventuellement, relativement sérieux donc, je me trompes ?
Mais ça risque de rester interne à jamais car les matèriels réseaux sont quand même beaucoup moins mis à jour (à tort) que les services mails et autre ...
Idéalement, si le fabriquant ne publie pas la faille+correctif endéant un délais raisonnable, c'est ta responsabilité d'avertir les utilisateurs (potentiels) du produit pour qu'ils puissent prendre les mesures nécessaires avant que quelqu'un d'autre de moins bien attentionné ne découvre la faille.
Je suis entierement d'accord avec toi mais certaines lois de notre pays sont dictées par des groupes qui ne sont pas d'accord avec nous ...
Je viens de les contacter, donc même en publiant en éwé depuis l'afghanistan sur un skyblog, ça va pas être dur de faire le rapprochement :)
J'attends de voir leurs réactions.
Tu cherche les gros clients utilisant le matériels puis tu envoie la faille a l'auteur + les gros client en cc.
Si c'est pas corrigé au bout d'une semaine, tu reenvoie l'e-mail avec les principales liste de secu en cc.
Normalement l'auteur corrige tres vite :)
# .
Posté par super_mario . Évalué à 10.
# J'ai jamais fait
Posté par jjl (site web personnel) . Évalué à 6.
- contacter [l'éditeur|le dev] en lui donnant tous les details (sans faire le pédant) voir une proof of concept
- quand il t'annonce que c'est corrigé ou au bout d'un temps raisonable (genre pas 2h) prévenir l'éditeur que tu va publier
- la publier en l'envoyant à des sites de sécurité (security focus, frsirt...)
- ne jamais diffuser publiquement l'eventuelle proof of concept
# Groupe de pirate
Posté par Nicolas Schoonbroodt . Évalué à 3.
Sinon tu peux contacter le créateur du logiciel, pour commencer, lui expliquer, et avec un peu de chance il corrigera vite. Sinon tu transmet aux sites de sécurités.
Et enfin, si c'est un logiciel libre, tu envois un patch ;-) (enfin, si tu as les compétences)
# Comment?
Posté par passant·e . Évalué à 10.
1 - Ceux qui sont pour la publication totale ("grand public" et constructeurs)
2 - Ceux qui n'avertissent que les constructeurs
3 - Ceux qui se gardent les failles pour eux
4 - Ceux qui publient la faille le jou même de la découverte
Bon on part du principe que tu veux rendre service donc on oublie les point 3 et 4.
Le point 1 est le plus utilisé. Il crée pas mal de discussion suite à la publication publique de la faille ainsi que l'exemple démontrant sa faisabilité il y a beaucoup de script kiddies qui piratent des centaines de serveurs. Cependant, il permet la reconnaissance à l'auteur de la découverte. Dans le cas du point 2, il arrive que le constructeur corrige discrétement la faille sans forcèment remercier celui qui a fait la découverte ce qui crée très souvent des problème d'égo...
Bon revenons à nos moutons comme publier la faille...
rain forest puppy a écrit un guide décrivant les étapes temporels à respecter pour la publication d'une faille.
http://www.wiretrip.net/rfp/policy.html
En gros
1 - tu avertis le fabricant que t'as trouvé un bug et que t'aimerais faire une publication publique
2 - le fabricant te réponds, tu lui donnes les détails techniques sur comment produire la faille (s'il ne répond pas après un certains temps tu publies la faille)
3 - tu lui laisses le temps de patcher ainsi que délai pour que les administrateurs puissent patcher
4 - tu la faille avec ou sans PoF (proof of concept) publies dans les principales listes de sécurités c'est-à-dire (securityfocus, muc.list.bugtraq, vulnwatch, full disclosure,...)
En espérant avoir répondu à ta question :-)
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: Comment?
Posté par rangzen (site web personnel) . Évalué à 4.
Je pense vraiment pas que ça interesse les scripts kiddies, c'est un cas assez particulier qui permet une élévation de privilège interne sur des matèriels réseaux. On en fait pas un vers quoi ...
Je vais déjà voir avec le constructeur, ce qu'il en pense. Mais ça risque de rester interne à jamais car les matèriels réseaux sont quand même beaucoup moins mis à jour (à tort) que les services mails et autre ...
[^] # Re: Comment?
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: Comment?
Posté par rangzen (site web personnel) . Évalué à 3.
Mais oui, c'est très ciblé.
[^] # Re: Comment?
Posté par Krunch (site web personnel) . Évalué à 4.
Ya des gens qui ont parlé de ça récemment sur leur blog :
http://metasploit.blogspot.com/2006/06/microsoft-is-disappoi(...)
http://addxorrol.blogspot.com/2006/06/on-bug-disclosure-and-(...)
Voire aussi les liens externe de Wikipédia sur le sujet :
http://en.wikipedia.org/wiki/Full_disclosure#External_links
Et puis je sais plus comment j'étais tombé sur ça aussi :
http://www.ranum.com/security/computer_security/editorials/d(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Comment?
Posté par rangzen (site web personnel) . Évalué à 3.
Je viens de les contacter, donc même en publiant en éwé depuis l'afghanistan sur un skyblog, ça va pas être dur de faire le rapprochement :)
J'attends de voir leurs réactions.
[^] # Re: Comment?
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Comment?
Posté par Olivier Guerrier . Évalué à 2.
# Linuxfr?
Posté par Nitchevo (site web personnel) . Évalué à 5.
# Methode efficace.
Posté par inico (site web personnel) . Évalué à 5.
Si c'est pas corrigé au bout d'une semaine, tu reenvoie l'e-mail avec les principales liste de secu en cc.
Normalement l'auteur corrige tres vite :)
# CERT
Posté par syntaxerror . Évalué à 2.
http://www.certa.ssi.gouv.fr/certa/cert.html
Par exemple le CERTA: http://www.certa.ssi.gouv.fr/certa/contact.html
ou le formulaire kivabien pour le Cert-IST: http://www.cert-ist.com/fra/contacts/declarerVulnerabilite/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.