Il y a trois semaines, un problème de sécurité sérieux dans OS X 10.10.4 a été découvert. Cela, en soi, n'est pas particulièrement intéressant.
Les failles de sécurité dans les progiciels les plus répandus sont constamment découvertes et OS X ne fait pas exception. La base de données de vulnérabilités Open Source (OSVDB) indique au moins 1100 vulnérabilités étiquetées comme "OS X". Mais ce qui est intéressant, c'est la façon dont cette vulnérabilité particulière a été révélée.
Plutôt que de dire à 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 était une course aux armements entre Apple et les hackers au chapeau noir. Apple a dû publier un correctif avant que la vulnérabilité ne soit armé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 dire que c'est contraire à l'éthique ou imprudent. Mais c'est plus compliqué que ça. Bienvenue dans le monde étrange et confus de la divulgation de la vulnérabilité.
Full vs Responsible Divulgation
Il existe deux façons populaires de divulguer les vulnérabilités aux fournisseurs de logiciels.
Le premier s'appelle la divulgation complète . Tout comme dans l'exemple précédent, les chercheurs publient immédiatement leur vulnérabilité dans la nature, ce qui ne donne absolument aucune chance aux éditeurs de publier un correctif.
La seconde est appelée divulgation responsable, ou divulgation échelonnée. C'est là que le chercheur contacte le fournisseur avant que la vulnérabilité ne soit publiée.
Les deux parties conviennent alors d'un délai dans lequel le chercheur s'engage à ne pas publier la vulnérabilité, afin de donner au fournisseur la possibilité de créer et de publier un correctif. Cette période peut varier de 30 jours à un an, selon la gravité et la complexité de la vulnérabilité. Certaines failles de sécurité ne peuvent pas être réparées facilement et nécessitent la reconstruction de systèmes logiciels entiers.
Une fois que les deux parties sont satisfaites du correctif produit, la vulnérabilité est alors divulguée et reçoit un numéro CVE. Ils 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 temps 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éagi ou se comporte, ou s'il estime que la demande de prolongation est déraisonnable, il peut simplement le publier en ligne sans aucune solution.
Dans le domaine de la sécurité, il existe des débats passionnés 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 vendeurs la possibilité 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 parties.
Les arguments en faveur de la divulgation responsable
Regardons un exemple où il était préférable d'utiliser la divulgation responsable.
Lorsque nous parlons d'infrastructure critique 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 une belle matin, versez-vous une tasse de café, puis asseyez-vous à votre ordinateur pour commencer votre travail pour la journée. Avant que vous obtenez réellement ... 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 sur le plan technique. Il y a beaucoup de confiance dans ce système. Nous croyons que lorsque nous tapons une adresse Web, nous sommes envoyés au bon endroit. Il y a tout simplement beaucoup à faire pour protéger 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 potentiel de dommages. Par exemple, ils pourraient envoyer des gens à des pages bancaires frauduleuses en ligne, leur permettant ainsi d'obtenir leurs coordonnées bancaires en ligne. Ils pourraient intercepter leurs e-mails et leur trafic en ligne à travers une attaque d'homme-dans-le-milieu et lire le contenu. Ils pourraient fondamentalement saper la sécurité d'Internet dans son ensemble. Trucs effrayants.
Dan Kaminsky est un chercheur en sécurité très respecté, avec un long résumé de la découverte de vulnérabilités dans des logiciels bien connus. Mais il est surtout connu pour la découverte en 2008 de la vulnérabilité la plus grave du système DNS jamais découverte. Cela aurait permis à quelqu'un d'effectuer facilement une attaque d'empoisonnement du cache (ou de spoofing DNS) 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, tout à fait conscient des conséquences de la publication d'une faille aussi grave, a décidé de la divulguer aux vendeurs du logiciel DNS concernés par ce bug.
Un certain nombre de produits DNS majeurs ont été touchés, notamment ceux fabriqués par Alcatel-Lucent, BlueCoat Technologies, Apple et Cisco. Le problème a également affecté un certain nombre d'implémentations DNS livrées avec certaines distributions Linux / BSD populaires, notamment celles de 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 ce problème était si grave, et les dommages potentiels si grands, qu'il aurait été incroyablement imprudent de le publier publiquement sans donner aux fournisseurs la possibilité d'émettre un correctif.
Incidemment, la vulnérabilité a été divulguée par accident par la société de sécurité Matsano dans un blog. L'article a été retiré, mais il a été reflété, et un jour après la publication un exploit Voici comment ils vous piratent: Le monde trouble des kits d'exploitation Voici comment ils vous piratent: Le monde trouble des kits Exploit Les escrocs 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 peuvent-ils être arrêtés? Lire la suite a été créé.
La vulnérabilité du DNS de Kaminsky résume en fin de compte l'essentiel de l'argument en faveur d'une divulgation responsable et échelonnée. Certaines vulnérabilités - comme les vulnérabilités zero day Qu'est-ce qu'une vulnérabilité Zero Day? [MakeUseOf Explique] Qu'est-ce qu'une vulnérabilité Zero Day? [MakeUseOf Explains] Lire la suite - sont si importants, que les publier publiquement causerait des dégâts importants.
Mais il y a aussi un argument convaincant en faveur de ne pas donner d'avertissement préalable.
L'argument en faveur de la divulgation complète
En libérant une vulnérabilité à l'air libre, vous déverrouillez la boîte d'un pandora où des individus peu recommandables peuvent rapidement et facilement produire des exploits, et compromettre les systèmes vulnérables. Alors, pourquoi quelqu'un aurait-il choisi de faire ça?
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 faire de publicité Pourquoi les entreprises qui enfreignent un secret pourraient être une bonne chose Pourquoi les entreprises qui gardent des violations un secret pourrait être une bonne chose Avec tant 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 Etats-Unis afin de vous protéger. Cela semble fou, alors qu'est-ce qui se passe? Lire la suite le fait qu'ils livraient des logiciels vulnérables. Une divulgation complète les oblige à être honnêtes avec leurs clients.
Apparemment @PepsiCo ne se soucie pas d'une vuln dans leur site, n'acceptant pas d'aide non sollicitée. A déjà une équipe sec. Je vais faire une divulgation complète
- Paquet blanc (@WhitePacket) 4 septembre 2015
Mais cela permet également aux consommateurs de choisir en connaissance de cause s'ils veulent continuer à utiliser un logiciel particulier et vulnérable. J'imagine que la majorité ne le ferait pas.
Que veulent les vendeurs?
Les fournisseurs n'aiment vraiment pas la divulgation complète.
Après tout, c'est incroyablement mauvais pour eux, et cela met leurs clients en danger. Ils ont essayé d'inciter les gens à divulguer des vulnérabilités de manière responsable grâce à des programmes de primes de bogues. Ceux-ci ont été remarquablement réussis, avec Google payant 1, 3 millions de dollars en 2014 seulement.
Bien que cela vaut la peine de souligner que certaines entreprises - comme Oracle Oracle veut que vous arrêtiez de les envoyer - Voici pourquoi c'est fou Oracle veut que vous arrêtiez de les envoyer - Voici pourquoi c'est fou Oracle est dans l'eau chaude sur un blog mal orienté 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'é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 de sécurité sur leur logiciel.
Mais il y aura toujours des gens qui insistent pour utiliser la divulgation complète, soit pour des raisons philosophiques, soit pour leur propre amusement. Aucun programme de prime de bogue, peu importe sa générosité, peut contrer cela.