Publicité
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, n'est pas particulièrement intéressant.
Des vulnérabilités de sécurité dans des progiciels populaires sont découvertes tout le tempset OS X ne fait pas exception. La base de données de vulnérabilités Open Source (OSVDB) affiche au moins 1 100 vulnérabilités marquées «OS X». Mais quoi est intéressante est la façon dont cette vulnérabilité particulière a été révélée.
Plutôt que d'en parler à Apple et de leur donner 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 a été une course aux armements entre Apple et les pirates informatiques. Apple a dû publier un correctif avant que la vulnérabilité ne soit militarisée, et les pirates ont dû créer un exploit avant que les systèmes à risque ne soient corrigés.
Vous pourriez penser que cette méthode particulière de divulgation est irresponsable. Vous pourriez même appeler cela contraire à l'éthique ou imprudent. Mais c'est plus compliqué que ça. Bienvenue dans le monde étrange et déroutant de la divulgation de vulnérabilités.
Divulgation complète vs responsable
Il existe deux façons populaires de divulguer des vulnérabilités aux éditeurs de logiciels.
Le premier s'appelle divulgation complète. Tout comme dans l'exemple précédent, les chercheurs publient immédiatement leur vulnérabilité dans la nature, ne donnant aux vendeurs absolument aucune possibilité de publier un correctif.
Le second s'appelle divulgation responsableou divulgation échelonnée. C'est là que le chercheur contacte le fournisseur avant la publication de la vulnérabilité.
Les deux parties s'accordent ensuite sur un délai dans lequel le chercheur promet de ne pas publier la vulnérabilité, afin de donner au vendeur la possibilité de créer et de publier un correctif. Cette période peut aller de 30 jours à un an, selon la gravité et la complexité de la vulnérabilité. Certains trous de sécurité ne peuvent pas être corrigés facilement et nécessitent la reconstruction complète de systèmes logiciels entiers.
Une fois que les deux parties sont satisfaites du correctif qui a été produit, la vulnérabilité est ensuite révélée et reçoit un Numéro CVE. Celles-ci identifient de manière unique chaque vulnérabilité, et la vulnérabilité est archivée en ligne sur l'OSVDB.
Mais que se passe-t-il si le délai d'attente expire? Eh bien, l'une des deux choses. Le vendeur négociera alors une prolongation avec le chercheur. Mais si le chercheur n'est pas satisfait de la façon dont le fournisseur a répondu ou s'est comporté, ou s'il estime que la demande d'extension est déraisonnable, il peut simplement la publier en ligne sans aucun correctif.
Dans le domaine de la sécurité, il y a des débats houleux 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 la possibilité de résoudre un problème avant de le diffuser dans la nature.
Il s'avère qu'il existe des arguments convaincants pour les deux parties.
Les arguments en faveur d'une divulgation responsable
Voyons un exemple de la meilleure façon d'utiliser la divulgation responsable.
Lorsque nous parlons d’infrastructure critique dans le contexte d’Internet, il est difficile d’éviter de parler de le protocole DNS Comment changer vos serveurs DNS et améliorer la sécurité InternetImaginez ceci: vous vous réveillez un beau matin, vous versez une tasse de café, puis vous asseyez devant votre ordinateur pour commencer votre travail de la journée. Avant de réellement obtenir ... Lire la suite . 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. Il y a tout simplement beaucoup à faire sur l'intégrité de ce système.
Si quelqu'un a pu interférer ou compromettre une demande DNS, il y a beaucoup de risques de dommages. Par exemple, ils pourraient envoyer des personnes vers des pages bancaires en ligne frauduleuses, leur permettant ainsi d'obtenir leurs coordonnées bancaires en ligne. Ils pouvaient intercepter leurs e-mails et le trafic en ligne via une attaque de l'homme du milieu et en lire le contenu. Ils pourraient fondamentalement compromettre la sécurité d'Internet dans son ensemble. Des trucs effrayants.
Dan Kaminsky est un chercheur en sécurité très respecté, avec un long résumé de la recherche de vulnérabilités dans des logiciels bien connus. Mais il est surtout connu pour la découverte en 2008 de vulnérabilité la plus grave dans le système DNS jamais trouvé. Cela aurait permis à quelqu'un d'effectuer facilement une empoisonnement du cache (ou usurpation DNS) attaque sur un serveur de noms DNS. Les détails plus techniques de cette vulnérabilité ont été expliqués lors de la conférence Def Con 2008.
Kaminsky, parfaitement conscient des conséquences de la publication d'une faille aussi grave, a décidé de la divulguer aux fournisseurs des logiciels DNS concernés par ce bogue.
Un certain nombre de produits DNS majeurs ont été affectés, y compris ceux construits par Alcatel-Lucent, BlueCoat Technologies, Apple et Cisco. Le problème a également affecté un certain nombre d'implémentations DNS fournies avec certaines distributions Linux / BSD populaires, y compris 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 ce problème était si grave et les dommages potentiels si importants qu’il aurait été incroyablement téméraire de le publier sans donner aux fournisseurs la possibilité d'émettre un pièce.
Soit dit en passant, la vulnérabilité était fuite par accident par la société de sécurité Matsano dans un article de blog. L'article a été retiré, mais il a été reflété, et un jour après sa publication un exploit Voici comment ils vous piratent: le monde trouble des kits d'exploitationLes fraudeurs peuvent utiliser des suites logicielles pour exploiter les vulnérabilités et créer des logiciels malveillants. Mais quels sont ces kits d'exploit? D'où viennent-ils? Et comment les arrêter? Lire la suite avait été créé.
La vulnérabilité DNS de Kaminsky résume finalement l'essentiel de l'argument en faveur d'une divulgation responsable et échelonnée. Certaines vulnérabilités - comme vulnérabilités zero day Qu'est-ce qu'une vulnérabilité Zero Day? [MakeUseOf explique] Lire la suite - sont si importants que leur divulgation publique entraînerait des dommages importants.
Mais il existe également un argument convaincant en faveur de l’absence d’alerte préalable.
Les arguments en faveur d'une divulgation complète
En libérant une vulnérabilité à l'air libre, vous déverrouillez une boîte de pandore où des individus peu recommandables peuvent rapidement et facilement produire des exploits et compromettre des systèmes vulnérables. Alors, pourquoi quelqu'un choisirait-il de faire cela?
Il y a plusieurs raisons. Premièrement, les fournisseurs sont souvent assez 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 à réagir rapidement. Pire encore, certains sont enclins ne pas publier Pourquoi les entreprises gardant les infractions secrètes pourraient être une bonne choseAvec autant d'informations en ligne, nous nous inquiétons tous des failles de sécurité potentielles. Mais ces violations pourraient être gardées secrètes aux États-Unis afin de vous protéger. Cela semble fou, alors que se passe-t-il? Lire la suite le fait qu'ils expédiaient des logiciels vulnérables. Une 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 particulier et vulnérable. J'imagine que la majorité ne le ferait pas.
Que veulent les vendeurs?
Les vendeurs n'aiment pas vraiment la divulgation complète.
Après tout, c'est incroyablement mauvais relations publiques pour eux, 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 primes aux bogues. Ceux-ci ont connu un succès remarquable, Google payant 1,3 million de dollars en 2014 seulement.
Même s'il convient de souligner que certaines entreprises - comme Oracle Oracle veut que vous cessiez de leur envoyer des bugs - voici pourquoi c'est fouOracle est dans l'eau chaude sur un article de blog malavisé du chef de la sécurité, Mary Davidson. Cette démonstration de la façon dont la philosophie de sécurité d'Oracle s'écarte du courant dominant n'a pas été bien reçue dans la communauté de la sécurité ... Lire la suite - décourager les gens d'effectuer des recherches sur la sécurité de leur logiciel.
Mais il y aura toujours des gens qui insisteront pour utiliser la divulgation complète, soit pour des raisons philosophiques, soit pour leur propre plaisir. Aucun programme de primes aux bogues, aussi généreux soit-il, ne peut contrer cela.
Matthew Hughes est un développeur de logiciels et écrivain de Liverpool, en Angleterre. Il est rarement trouvé sans une tasse de café noir fort dans sa main et adore absolument son Macbook Pro et son appareil photo. Vous pouvez lire son blog sur http://www.matthewhughes.co.uk et suivez-le sur twitter à @matthewhughes.