Comment divulguer une vulnérabilité de sécurité de manière éthique?
Comment divulguer une vulnérabilité de sécurité de manière éthique? J'ai entendu dire qu'il existe différentes écoles de pensée sur ce sujet. J'aimerais connaître les avantages/inconvénients de chacun.
Vous devez informer le (s) développeur (s) en privé afin qu'ils aient la possibilité de le corriger. Après cela, si et quand vous rendez public la vulnérabilité, vous devez laisser suffisamment de temps au développeur pour résoudre le problème et à quiconque y est exposé suffisamment de temps pour mettre à niveau ses systèmes. Personnellement, je permettrais au développeur de faire l'annonce dans un bulletin de sécurité dans la plupart des cas plutôt que de l'annoncer moi-même. À tout le moins, j'attendrais la confirmation que la vulnérabilité a été corrigée. Si vous avez le temps et avez accès au code source, vous pouvez également fournir un correctif.
Personnellement, je pense que divulgation responsable semble être la meilleure façon de passer d'un point de vue éthique et a bien fonctionné pour Dan Kaminsky révélant les détails de la vulnérabilité d'empoisonnement du cache DNS. Mais tout dépend en grande partie de la société ou du groupe avec lequel vous traitez et également de la base d'utilisateurs qu'elle affectera.
@VirtuosiMedia fait un excellent travail en décrivant la "divulgation responsable".
J'ajouterais deux points:
- Travaillez avec le fournisseur (si vous le pouvez), pour vous assurer qu'il le comprend parfaitement et qu'il n'émet pas de patch à moitié cuit.
- Si le vendeur vous ignore ou vous ignore, continuez d'essayer. Cependant, s'ils prétendent que ce n'est pas une vulnérabilité, allez-y et publiez. Aussi fort que possible. S'ils ont promis de réparer, mais ne le font pas, essayez d'obtenir une réponse d'eux, ainsi qu'un calendrier définitif auquel ils s'engagent. À un moment donné, s'ils continuent de reporter, vous voudrez peut-être éventuellement leur dire que vous allez publier de toute façon - puis leur donner un peu de temps pour le corriger (mais court et limité).
Ceci est un diable d'un sujet complexe. J'ai été impliqué dans la divulgation du bogue de renégociation TLS il y a quelques années, et croyez-moi, nous avons fait de notre mieux pour être "responsables", mais à la fin, nous avons réussi principalement à énerver tout le monde autour de nous et (peut-être) à retarder la version actuelle du correctif. Cela ne veut pas dire que la notification du fournisseur est nécessairement mauvaise, mais seulement qu'il est vraiment facile de se faire fouetter et de finir en causant autant de mal que de bien, ou pire.
Dans notre cas, il a fallu une action de l'IETF ( RFC 5746 ) pour résoudre le problème, et même si nous avions un projet Internet prêt le jour de sa fuite, le travail réel de débattre et de décider de la solution a pris environ trois mois de plus et n'a vraiment commencé véritablement que lorsque la divulgation a eu lieu.
Quoi qu'il en soit, ce n'est pas une réponse à votre question, mais c'est l'une des histoires de divulgation les plus intéressantes que je connaisse. Plus sur cette histoire dans le 2010 ShmooCon keynote Je l'ai fait avec Marsh Ray, qui a découvert le problème.
En général, cela dépend de la réponse du fournisseur. La bonne pratique est lorsque le chercheur en sécurité informe le vendeur de la vulnérabilité, puis pendant la conversation, vous parlez des conditions de publication de poc/exploit de cette vulnérabilité. En fait, le chercheur choisit ce qu'il faut faire avec cette vulnérabilité - publier plus tard ou non. Le fournisseur publie ensuite le correctif ou la nouvelle version du produit. Peut être. Mais, comme le montre l'expérience - tous les fournisseurs ne sont pas si gentils. Certains corrigent des bugs en silence, sans en informer les utilisateurs finaux et les chercheurs, certains préfèrent ignorer les chercheurs. D'autres tentent même de poursuivre. C'est pourquoi, parfois, l'anonymat est un moyen préférable de communication initiale avec un fournisseur inconnu.
Je voudrais également admettre qu'il existe des programmes de récompense de primes de bogues - ceux proposés par Google, Mozilla. En outre, d'autres achètent des vulnérabilités - ZDI , iDefense , SNOsoft , à venir "hub d'exploitation", et etc. Il y a donc au moins trois façons d'informer le fournisseur - directement, en publiant des informations sur les vulnérabilités sur une liste ou via des sociétés tierces.
S'ils ont un outil de suivi des problèmes publics, voyez si vous pouvez déposer un bogue avec une étiquette "privée" ou "de sécurité".
Qu'ils disposent ou non d'un outil de suivi des problèmes, envoyez un e-mail security@ nom de l'entreprise et faites-le-leur savoir.
S'ils ne répondent pas assez rapidement (voir "Fenêtre de divulgation" dans l'article de Schneier ci-dessous), alors vous devez penser à le divulguer plus largement. Recherchez les listes de diffusion sur lesquelles se cachent les universitaires/professionnels de la sécurité et demandez-leur comment ils signalent les problèmes au fournisseur en question. Ils peuvent être en mesure de faire des présentations au bon endroit dans l'organisation.
Si tout cela échoue, lisez le bit Schneier et demandez-vous si une divulgation complète ferait partie du problème ou de la solution.
Bruce Schneier donne un argument pour divulgation complète dans certaines circonstances sur la base d'une norme "faire partie de la solution, pas du problème". Cela vaut vraiment la peine d'être lu.
Il s'agit du débat classique "secret des bogues contre divulgation complète". J'ai déjà écrit à ce sujet dans Crypto-Gram; d'autres ont également écrit à ce sujet. C'est un problème compliqué avec des implications subtiles dans toute la sécurité informatique, et il vaut la peine d'en discuter à nouveau.
...
Ce flux d'informations gratuit, à la fois de description et de code de preuve de concept, est également vital pour la recherche en matière de sécurité. La recherche et le développement en matière de sécurité informatique se sont développés au cours de la dernière décennie, et une grande partie de cela peut être attribuée au mouvement de divulgation complète. La possibilité de publier des résultats de recherche - bons ou mauvais - conduit à une meilleure sécurité pour tout le monde. Sans publication, la communauté de la sécurité ne peut apprendre des erreurs des autres. Tout le monde doit fonctionner avec des oeillères, faisant les mêmes erreurs encore et encore. Une divulgation complète est essentielle si nous voulons continuer à améliorer la sécurité de nos ordinateurs et réseaux.
...
Deuxièmement, je crois qu'il faut donner un préavis au vendeur. Le CERT a poussé les choses à l'extrême, donnant parfois au vendeur des années pour résoudre le problème.
...
J'aime la mesure "faire partie de la solution, pas du problème". La recherche de la sécurité fait partie de la solution. Convaincre les fournisseurs de résoudre les problèmes fait partie de la solution. Semer la peur fait partie du problème. La remise d'outils d'attaque à des adolescents désemparés fait partie du problème.