Vous devez informer le (s) développeur (s) en privé afin qu'ils aient une chance de résoudre le problème. Après cela, si et quand vous devenez public avec la vulnérabilité, vous devez laisser au développeur suffisamment de temps pour résoudre le problème et à quiconque y est exposé suffisamment de temps pour mettre à niveau ses systèmes. Personnellement, j'autoriserais le développeur à 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 la divulgation responsable semble être le meilleur moyen d'aller d'un point de vue éthique et a bien fonctionné pour Dan Kaminsky en révélant les détails de la vulnérabilité d'empoisonnement du cache DNS. Mais tout dépend grandement de l'entreprise ou du groupe avec lequel vous traitez et de la base d'utilisateurs que cela 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 ne publie pas un patch à moitié cuit.
• Si le fournisseur vous ignore ou vous ignore, continuez à 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 corriger, mais ne le font pas, essayez d'obtenir une réponse de leur part, ainsi qu'un calendrier définitif auquel ils s'engagent. À un moment donné, s'ils continuent de reporter, vous voudrez peut-être leur dire que vous allez publier de toute façon - puis leur donner le temps de le réparer (mais court et limité.)

C'est un sacré 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 essayé très fort d'être "responsables", mais au final, nous avons surtout réussi à faire chier 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 par causer autant de tort 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ébat et de décision sur la solution a pris environ trois mois de plus, et n'a pas vraiment commencer sérieusement jusqu'à ce que la divulgation ait 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 d'informations sur cette histoire dans le discours d'ouverture de la ShmooCon 2010 que j'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 fournisseur 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 quoi faire avec cette vulnérabilité - publier plus tard ou non. Ensuite, le fournisseur publie un correctif ou une nouvelle version du produit. Peut être. Mais, comme le montre l'expérience - tous les fournisseurs ne sont pas si gentils. Certains d'entre eux corrigent les bugs en silence, sans informer les utilisateurs finaux et les chercheurs, certains préfèrent ignorer les chercheurs. D'autres essaient même de poursuivre. C'est pourquoi l'anonymat est parfois le moyen préférable de communiquer avec un fournisseur inconnu.

Je voudrais également admettre qu'il existe des programmes de récompenses de bugs - ceux proposés par Google, Mozilla. En outre, d'autres achètent des vulnérabilités - ZDI, iDefense, SNOsoft, à venir "Exploit Hub", etc. Donc, il y a au moins trois façons comment informer le fournisseur - directement, en publiant des informations de vulnérabilité sur une liste ou via des sociétés tierces.

S'ils ont un outil de suivi des problèmes public, voyez si vous pouvez signaler un bogue avec une étiquette "privé" ou "sécurité".

Qu'ils aient ou non un outil de suivi des problèmes, envoyez sécurité @ nom de l'entreprise et faites-leur savoir.

S'ils ne répondent pas assez rapidement (voir «Fenêtre de divulgation» dans l'article Schneier ci-dessous), vous devez réfléchir de le divulguer plus largement. Recherchez des listes de diffusion sur lesquelles les universitaires / professionnels de la sécurité se cachent et demandez-leur comment ils signalent les problèmes au fournisseur en question. Ils pourront peut-être faire des présentations au bon endroit dans l'organisation.

Si tout cela échoue, lisez le bit Schneier et réfléchissez à la question de savoir si la divulgation complète ferait partie du problème ou de la solution.

Bruce Schneier donne un argument en faveur de la divulgation complète dans certaines circonstances en se basant sur un standard «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 de bogue 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 sur la sécurité informatique, et il vaut la peine d'en discuter à nouveau.

...

Ce flux d'informations gratuit, à la fois de description et de preuve de concept code, est également vital pour la recherche sur la sécurité. La recherche et le développement dans le domaine de la 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 tous. Sans publication, la communauté de la sécurité ne peut pas apprendre des erreurs de l'autre. Tout le monde doit opérer avec des œillères, faire 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 de nos réseaux.

...

Deuxièmement, je crois qu'il est important de donner un préavis au fournisseur. Le CERT a poussé cela à l'extrême, donnant parfois des années au fournisseur pour résoudre le problème.

...

J'aime le "faire partie de la solution, pas du problème" métrique. La recherche sur 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. Remettre des outils d'attaque à des adolescents désemparés fait partie du problème.