Divulgation complète ou responsable de la divulgation des vulnérabilités de sécurité

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

Des vulnérabilités de sécurité dans des progiciels populaires sont découvertes tout le temps, et OS X ne fait pas exception. La base de données de vulnérabilités Open Source (OSVDB) contient au moins 1100 vulnérabilités identifiées comme “OS X”. Mais quoi est intéressant est la façon dont cette vulnérabilité particulière a été révélée.

Plutôt que de le dire à Apple et de lui laisser le temps de remédier au problème, le chercheur a décidé de publier son exploit sur Internet pour que tout le monde puisse le voir..

Le résultat final fut une course aux armements entre Apple et des hackers au chapeau noir. Apple devait publier un correctif avant que la vulnérabilité ne devienne une arme, et les pirates informatiques devaient créer un exploit avant que les systèmes à risque ne soient corrigés..

Vous pourriez penser que cette méthode de divulgation est irresponsable. Vous pouvez même appeler cela contraire à l'éthique ou téméraire. Mais c'est plus compliqué que ça. Bienvenue dans le monde étrange et déroutant de la divulgation des vulnérabilités.

Divulgation complète ou responsable

Il existe deux manières courantes de révéler les vulnérabilités aux éditeurs de logiciels..

Le premier s'appelle divulgation complète. Comme dans l'exemple précédent, les chercheurs publient immédiatement leur vulnérabilité dans la nature, ne donnant aux vendeurs aucune occasion de publier un correctif..

La seconde s'appelle divulgation responsable, ou une divulgation échelonnée. C’est là que le chercheur contacte le fournisseur avant la publication de la vulnérabilité..

Les deux parties conviennent alors d'un délai dans lequel le chercheur promet de ne pas publier la vulnérabilité, afin de donner au fournisseur l'occasion de créer et de publier un correctif. Cette période peut aller de 30 jours à un an, en fonction de la gravité et de la complexité de la vulnérabilité. Certaines failles de sécurité ne peuvent pas être corrigées facilement et nécessitent la reconstruction complète de systèmes logiciels..

Une fois que les deux parties sont satisfaites du correctif produit, la vulnérabilité est ensuite divulguée et un numéro CVE lui est attribué. Celles-ci identifient de manière unique chaque vulnérabilité et celle-ci est archivée en ligne sur la mémoire OSVDB..

Mais que se passe-t-il si le délai d'attente expire? Eh bien, une des deux choses. Le fournisseur négociera ensuite une extension avec le chercheur. Mais si le chercheur n'est pas satisfait de la réponse ou du comportement du fournisseur, ou s'il estime que la demande d'extension est déraisonnable, il peut simplement la publier en ligne sans solution préalable..

Dans le domaine de la sécurité, des débats houleux ont eu lieu sur la meilleure méthode de divulgation. 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 fournisseurs l'occasion de résoudre un problème avant de le relâcher dans la nature..

En fin de compte, il existe des arguments convaincants pour les deux côtés.

Les arguments en faveur d'une divulgation responsable

Regardons un exemple de la meilleure utilisation de la divulgation responsable.

Lorsque nous parlons d'infrastructures critiques dans le contexte d'Internet, il est difficile d'éviter de parler du protocole DNS. Comment changer vos serveurs DNS et améliorer la sécurité Internet Comment changer vos serveurs DNS et améliorer la sécurité Internet Imaginez ceci - vous vous réveillez Au matin, sers-toi une tasse de café, puis assieds-toi devant ton ordinateur pour commencer ton travail de la journée. Avant que vous obteniez réellement…. C’est ce qui nous permet de traduire des adresses Web lisibles par l’homme (comme makeuseof.com) en adresses IP..

Le système DNS est incroyablement compliqué, et pas seulement au niveau technique. Il y a beaucoup de confiance dans ce système. Nous espérons que lorsque nous tapons une adresse Web, nous sommes envoyés au bon endroit. L'intégrité de ce système dépend beaucoup de l'intégrité de ce système.

Si quelqu'un était capable d'interférer avec ou de compromettre une requête DNS, il y a beaucoup de risque de dommages. Par exemple, ils pourraient envoyer des personnes vers des pages de banque en ligne frauduleuses, leur permettant ainsi d’obtenir leurs coordonnées bancaires en ligne. Ils pourraient intercepter leurs e-mails et leur trafic en ligne via une attaque de type "man-in-the-middle" et lire le contenu. Ils pourraient nuire fondamentalement à la sécurité d'Internet dans son ensemble. Truc effrayant.

Dan Kaminsky est un chercheur en sécurité très respecté, qui a longtemps résumé les vulnérabilités de logiciels réputés. Mais il est surtout connu pour la découverte, en 2008, de la vulnérabilité probablement la plus grave du système DNS. Cela aurait permis à quelqu'un d'effectuer facilement une attaque par empoisonnement du cache (ou usurpation de DNS) sur un serveur de noms DNS. Les détails plus techniques de cette vulnérabilité ont été expliqués à la conférence Def Con 2008.

Kaminsky, parfaitement conscient des conséquences de la publication d'une telle faille grave, a décidé de la divulguer aux fournisseurs du logiciel DNS concernés par ce bogue..

Un certain nombre de produits DNS importants ont été concernés, notamment ceux développés par Alcatel-Lucent, BlueCoat Technologies, Apple et Cisco. Le problème concernait également un certain nombre d'implémentations DNS fournies avec certaines distributions populaires Linux / BSD, notamment celles pour Debian, Arch, Gentoo et FreeBSD..

Kaminsky leur a donné 150 jours pour produire un correctif et a travaillé avec eux en secret pour les aider à comprendre la vulnérabilité. Il savait que le problème était si grave et les dommages potentiels si importants qu'il aurait été incroyablement imprudent de le publier publiquement sans donner aux vendeurs l'occasion de publier un correctif..

Incidemment, la vulnérabilité a été révélée accidentellement par la société de sécurité Matsano dans un article de blog. Cet article a été supprimé, mais il a été mis en miroir et, un jour après la publication, un exploit intitulé Voici comment ils vous piratent: le monde obscur des kits d’exploitation Voici comment ils vous piratent: le monde obscur des kits d’exploitation Les fraudeurs peuvent utiliser des suites logicielles pour exploiter les vulnérabilités et créer des logiciels malveillants. Mais quels sont ces kits d'exploits? D'où viennent-ils? Et comment peuvent-ils être arrêtés? avait été créé.

La vulnérabilité DNS de Kaminsky résume en définitive le nœud de l'argument en faveur d'une divulgation responsable et échelonnée. Certaines vulnérabilités - telles que les vulnérabilités zéro jour Qu'est-ce qu'une vulnérabilité zéro jour? [MakeUseOf explique] Qu'est-ce qu'une vulnérabilité de jour zéro? [MakeUseOf explique] - sont si importants que leur publication causerait des dommages importants.

Mais il y a aussi un argument convaincant en faveur de ne pas donner d'avertissement.

L'argument en faveur d'une divulgation complète

En libérant une vulnérabilité à découvert, vous déverrouillez une boîte de pandore où des individus peu recommandables sont capables de produire rapidement et facilement des exploits et de compromettre des systèmes vulnérables. Alors, pourquoi quelqu'un choisirait-il de le faire?

Il y a plusieurs raisons. Premièrement, les fournisseurs tardent souvent beaucoup à 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éagir rapidement. Pire encore, certains sont enclins à ne pas publier pourquoi les entreprises gardant un secret en secret pourraient être une bonne chose. Pourquoi les entreprises gardant un secret en secret seraient une bonne chose. Avec autant d'informations en ligne, nous nous inquiétons tous des atteintes potentielles à la sécurité. Mais ces violations pourraient être tenues secrètes aux États-Unis afin de vous protéger. Cela semble fou, alors qu'est-ce qui se passe? le fait qu'ils livraient des logiciels vulnérables. La divulgation complète les oblige à être honnêtes avec leurs clients.

Mais cela permet également aux consommateurs de choisir en connaissance de cause s'ils souhaitent continuer à utiliser un logiciel en particulier et vulnérable. J'imagine que la majorité ne serait pas.

Que veulent les vendeurs?

Les vendeurs n'aiment pas la divulgation complète.

Après tout, c’est incroyablement mauvais pour les relations publiques et cela met leurs clients en danger. Ils ont essayé d'inciter les gens à divulguer les vulnérabilités de manière responsable par le biais de programmes de prime aux bogues. Celles-ci ont connu un succès remarquable, Google payant 1,3 million de dollars rien qu'en 2014..

Même si cela vaut la peine de souligner que certaines entreprises - comme Oracle, Oracle, veut que vous arrêtiez de leur envoyer des bogues - voici pourquoi c'est fou Oracle, veut que vous cessiez de leur envoyer des bogues - voici pourquoi c'est fou Oracle est en colère contre un blog erroné rédigé par le chef de la sécurité Mary Davidson. Cette démonstration de la façon dont la philosophie de sécurité d’Oracle s’éloigne de la norme n’a pas été bien accueillie par la communauté de la sécurité… - dissuadez les personnes d’effectuer des recherches sur la sécurité de leurs logiciels.

Mais il y aura toujours des gens qui insistent pour utiliser la divulgation complète, soit pour des raisons philosophiques, soit pour leur propre divertissement. Aucun programme de prime aux bogues, aussi généreux soit-il, ne peut contrer cela.