La divulgation complète ou responsable: comment les failles de sécurité sont divulgués

Video: Lynis audit de sécurité sous Kali Linux

Il y a trois semaines, un grave problème de sécurité dans OS X 10.10.4 a été découvert. Cela, en soi, est pas particulièrement intéressant.

Les failles de sécurité dans les logiciels populaires sont découverts tout le temps, et OS X ne fait pas exception. La base de données de vulnérabilité Open Source (OSVDB) montre au moins 1100 vulnérabilités dans la catégorie « OS X ». Mais quoi est intéressant est la façon dont cette vulnérabilité particulière a été divulguée.

Plutôt que de dire Apple et leur donner le temps de remédier à ce problème, le chercheur a décidé de poster son exploit sur Internet pour tout le monde à voir.

Le résultat final était une course aux armements entre Apple et les pirates chapeau noir. Apple a dû publier un correctif avant la vulnérabilité a été militarisé, et les pirates ont dû créer un exploit avant que les systèmes à risque patchées.

Vous pourriez penser que la méthode particulière de la divulgation est irresponsable. Vous pouvez même l`appeler contraire à l`éthique, ou téméraire. Mais il est plus compliqué que cela. Bienvenue dans le monde étrange, déroutant de la divulgation de la vulnérabilité.

Complète vs divulgation responsable

Il y a deux façons populaires de révéler les vulnérabilités aux éditeurs de logiciels.

La première est appelée divulgation complète. Tout comme dans l`exemple précédent, les chercheurs publient immédiatement leur vulnérabilité dans la nature, en donnant aux fournisseurs absolument aucune possibilité de sortir un correctif.

La seconde est appelée divulgation responsable, ou la communication décalée. C`est là que les contacts des chercheurs du vendeur avant la vulnérabilité est libéré.

Les deux parties conviennent alors sur un laps de temps où le chercheur promet de ne pas publier la vulnérabilité, afin de donner au vendeur l`occasion de construire et libérer un correctif. Cette période peut varier de 30 jours à un an, en fonction de la gravité et de la complexité de la vulnérabilité. Certains trous de sécurité ne peuvent pas être facilement résolus et nécessitent des systèmes de logiciels entiers à reconstruire à partir de zéro.

Une fois que les deux parties sont satisfaites de la solution qui a été produit, la vulnérabilité est ensuite divulguée et un numéro de CVE. Ces identifient de manière unique chaque vulnérabilité et la vulnérabilité sont archivées en ligne sur le OSVDB.

Mais ce qui se passe si le temps d`attente expire? Eh bien, l`une des deux choses. Le vendeur négociera ensuite une extension avec le chercheur. Mais si le chercheur est mécontent de la façon dont le vendeur a répondu ou élevés, ou ils se sentent la demande de prolongation est déraisonnable, ils pourraient tout simplement le publier en ligne avec pas de solution prêt.

Video: Tutoriel PHP - Sécurité, Les Failles CSRF

Dans le domaine de la sécurité, il y a des débats houleux quant à ce mode de communication est le meilleur. Certains pensent que la seule méthode éthique et précise est la divulgation complète. Certains pensent qu`il est préférable de donner aux vendeurs une occasion de résoudre un problème avant de le relâcher dans la nature.

Comme il se trouve, il y a des arguments convaincants pour les deux parties.

Les arguments en faveur de la divulgation responsable

Regardons un exemple où il est préférable d`utiliser la divulgation responsable.

Lorsque nous parlons d`infrastructures critiques dans le contexte de l`Internet, il est difficile d`éviter de parler le protocole DNS. C`est ce qui nous permet de traduire les adresses web lisibles par l`homme (comme makeuseof.com) en adresses IP.Comment faire pour changer vos serveurs DNS & Améliorer la sécurité InternetComment faire pour changer vos serveurs DNS & Améliorer la sécurité InternetImaginez - vous vous réveillez un beau matin, vous versez une tasse de café, et puis asseyez-vous à votre ordinateur pour commencer votre travail pour la journée. Avant de réellement obtenir ...Lire la suite

Le système DNS est incroyablement complexe, et pas seulement sur le plan technique. Il y a beaucoup de confiance placé dans ce système. Nous espérons que lorsque nous tapons dans une adresse Web, nous sommes envoyés au bon endroit. Il y a tout simplement beaucoup à cheval sur l`intégrité de ce système.

Si quelqu`un a pu interférer avec ou compromettre une requête DNS, il y a beaucoup de potentiel pour les dommages. Par exemple, ils pourraient envoyer des gens aux pages bancaires en ligne frauduleux, leur permettant ainsi d`obtenir leurs coordonnées bancaires en ligne. Ils pourraient intercepter leurs e-mails et le trafic en ligne à travers un homme-in-the-middle, et lire le contenu. Ils pourraient compromettre gravement la sécurité de l`Internet dans son ensemble. choses effrayantes.

Dan Kaminsky est un chercheur en sécurité bien respecté, avec un long résumé de trouver des vulnérabilités dans les logiciels bien connus. Mais il est surtout connu pour la découverte de 2008 peut-être la vulnérabilité la plus grave dans le système DNS jamais trouvé. Cela aurait permis à quelqu`un d`effectuer facilement un empoisonnement du cache (ou l`usurpation d`identité DNS) attaque sur un serveur de noms DNS. Les détails techniques de cette vulnérabilité ont été expliqués lors de la conférence Def Con 2008.

Kaminsky, pleinement conscients des conséquences de libérer un défaut grave, a décidé de les divulguer aux fournisseurs du logiciel DNS qui sont affectés par ce bug.

Il y avait un certain nombre de principaux produits DNS concernés, y compris ceux construits par Alcatel-Lucent, BlueCoat Technologies, Apple et Cisco. La question a également affecté un certain nombre d`implémentations DNS livré avec des distributions Linux populaires / BSD, y compris ceux pour Debian, Arch, Gentoo et FreeBSD.

Kaminsky leur a donné 150 jours pour produire une solution, et a travaillé avec eux en secret pour les aider à comprendre la vulnérabilité. Il savait que cette question était si grave, et les dommages potentiels si grand, qu`il aurait été incroyablement téméraire de libérer publiquement sans donner aux fournisseurs l`occasion de publier un correctif.

Par ailleurs, la vulnérabilité a été divulgué par accident par le cabinet de sécurité Matsano dans un billet de blog. L`article a été descendu, mais il a été en miroir, et un jour après la publication un exploit avait été créé.Voilà comment ils vous Hack: Le Murky World of Exploit KitsVoilà comment ils vous Hack: Le Murky World of Exploit KitsScammers peuvent utiliser des suites logicielles pour exploiter les vulnérabilités et créer des logiciels malveillants. Mais quels sont ces kits exploitent? D`où viennent-ils? Et comment peuvent-ils être arrêtés?Lire la suite

La vulnérabilité DNS de Kaminsky résume en fin de compte l`essentiel de l`argument en faveur de la divulgation responsable, échelonnée. Quelques vulnérabilités - comme zéro vulnérabilités jour - sont si importants, que de diffuser publiquement les causerait des dommages importants.

Mais il y a aussi un argument convaincant en faveur de ne pas donner un avertissement préalable.

Le cas de la divulgation complète

En libérant une vulnérabilité à l`air libre, vous déverrouillez la boîte de pandore où les individus peu recommandables sont en mesure de produire rapidement et facilement les exploits, et compromettre les systèmes vulnérables. Alors, pourquoi quelqu`un choisir de le faire?

Il y a deux raisons. Tout d`abord, les vendeurs sont souvent très lents à répondre aux notifications de sécurité. En forçant efficacement leur main en libérant une vulnérabilité dans la nature, ils sont plus motivés pour répondre rapidement. Pire encore, certains sont enclins de ne pas faire connaître le fait qu`ils expédiaient logiciels vulnérables. La divulgation complète les oblige à être honnête avec leurs clients.Pourquoi les entreprises Garder un secret pourrait Violations être une bonne chosePourquoi les entreprises Garder un secret pourrait Violations être une bonne choseAvec autant d`informations en ligne, nous inquiétons tous de failles de sécurité potentielles. Mais ces violations pourraient être gardées secrètes aux Etats-Unis afin de vous protéger. Cela semble fou, donc ce qui se passe?Lire la suite

Mais il permet aussi aux consommateurs de faire un choix éclairé quant à savoir si elles veulent continuer à utiliser un morceau particulier, vulnérable du logiciel. J`imagine que la majorité ne serait pas.

Qu`est-ce que les vendeurs veulent?

Les vendeurs n`aiment vraiment la divulgation complète.

Après tout, il est incroyablement mauvais PR pour eux, et il met ses clients à risque. Ils ont essayé d`inciter les gens à divulguer les vulnérabilités de façon responsable si les programmes de primes de bug. Celles-ci ont été un succès remarquable, avec Google payer 1,3 million de dollars en 2014 seulement.

Bien qu`il soit intéressant de souligner que certaines entreprises - comme Oracle - décourager les gens d`effectuer la recherche de la sécurité sur leur logiciel.Oracle veut que vous arrêter de les Envoi Bugs - Voici pourquoi est fouOracle veut que vous arrêter de les Envoi Bugs - Voici pourquoi est fouOracle est dans l`eau chaude sur un billet de blog égaré par le chef de la sécurité, Mary Davidson. Cette démonstration de la façon dont la philosophie de sécurité d`Oracle part du courant principal n`a pas été bien reçue dans la communauté de la sécurité ...Lire la suite

Mais il y aura toujours des gens qui insistent sur l`utilisation de la divulgation complète, que ce soit pour des raisons philosophiques, ou pour leur propre amusement. Aucun programme de primes bug, peu importe la générosité, peut contrer cela.