Question:
Responsabilité en cas de dommages aux États-Unis pour avoir découvert et divulgué une exploitation informatique «0-day»
Digital fire
2015-05-28 17:21:49 UTC
view on stackexchange narkive permalink

Dans le monde de la sécurité informatique / de programmation, les gens contactent généralement le fournisseur / propriétaire d'un logiciel particulier s'ils trouvent un bogue ou une vulnérabilité de sécurité et leur donnent le temps de le corriger avant de publier le bogue ou la vulnérabilité pour examen / sensibilisation du public. C'est généralement par courtoisie, sauf si vous êtes lié par contrat. Mais comme demandé dans Si je trouve ou crée un 0day: que se passe-t-il si je trouve une vulnérabilité dans un logiciel largement utilisé?

Puis-je être tenu responsable des dommages si je publie du code «Proof of Concept» au public sans donner au fournisseur le temps de corriger et de mettre à jour correctement son code vulnérable?

MISE À JOUR: Après avoir discuté de cette question avec certains pairs, J'ai réalisé que je devais être un peu plus précis avec la question: les chercheurs en sécurité travaillent généralement avec le fournisseur pour essayer de corriger (corriger) l'erreur / la vulnérabilité. Si après un délai suffisant (30 jours?) S'est écoulé et que le fournisseur n'a pas corrigé le code, une divulgation complète est rendue publique.

Puis-je être tenu responsable des dommages causés après la publication d'un code «Proof of Concept» si le logiciel / fournisseur est open source? Et si le fournisseur / logiciel est une source fermée?

Un répondre:
#1
+14
kevin
2015-05-28 18:53:45 UTC
view on stackexchange narkive permalink

Pouvez-vous être responsable des dommages? Sous Loi sur la responsabilité délictuelle, oui.

Supposons que quelqu'un a développé un virus basé sur votre code. Le virus a causé des millions de dollars de dommages. Le plaignant (éditeur de logiciel) peut faire valoir que:

  1. Vous avez un Devoir de diligence

pour éviter des actes ou des omissions que vous pouvez raisonnablement prévoir sont susceptibles de blesser votre voisin

Donoghue v. Stevenson (1932) (Royaume-Uni)

Le concept de devoir de diligence se retrouve également dans la législation américaine, par exemple dans MacPerson v. Buick Motor Co. (1916) , qui établit que négligence ne nécessite pas de contrat .

  1. Manquement au devoir: une personne raisonnable peut prévoir que la "preuve de concept" peut causer un préjudice. Le fait de publier du code ne répond donc pas à la norme attendue. Si vous êtes un professionnel de l'informatique, il sera difficile de défendre ce point.
  2. Il existe une relation de causalité entre votre code et les dommages qui en résultent.

  3. Vous êtes responsable de la négligence

  4. Dommages: Il Il est probable que les utilisateurs poursuivront le fournisseur de logiciels pour leurs pertes. Le fournisseur de logiciels vous poursuivra alors, car à cause de vous, l'éditeur de logiciels doit compenser ses clients.

Cela dépend bien sûr de ce que vous avez lancé exactement au public. Par exemple, si un effort important est nécessaire pour convertir votre «preuve de concept» en un véritable exploit et que vous avez fourni une solution de contournement pour éviter cette vulnérabilité, vous pouvez vous défendre en affirmant que le lien de cause à effet est trop distant .


Je dois donc garder le rapport privé? Et si le logiciel est open source?

Pas vraiment. Vous devez prendre des mesures raisonnables pour vous assurer que votre «preuve de concept» n'est pas un véritable exploit et qu'un pirate a besoin d'un temps considérable pour développer un logiciel malveillant fonctionnel. CVE est une plate-forme où les vulnérabilités sont partagées publiquement.


Que faire si vous avez donné au fournisseur un délai raisonnable pour corriger la vulnérabilité?

Peu importe (pour vous) si le temps a été donné au fournisseur pour corriger la vulnérabilité. Cela importe pour le fournisseur, car si quelque chose se produit plus tard, il est responsable de connaître le problème bien à l’avance et n’a pas alloué les ressources appropriées pour corriger le problème.

Pour démontrer qu’une vulnérabilité existe, il n’existe pas nécessitent des instructions sur la manière d'utiliser cette vulnérabilité. Par exemple, vous pouvez enregistrer une vidéo montrant les effets du piratage.


Ici (Wayback Machine; le lien d'origine est mort) est une lecture intéressante sur Motorola prenant les choses en compte de leurs propres mains après avoir découvert une vulnérabilité sur le système Xerox CP-V et Xerox n'a pas corrigé le problème.

J'ai mis à jour la question. Je pense que la réponse ne serait applicable qu'à une situation où la vulnérabilité se trouve dans un logiciel / matériel «source fermée».
Le cas que vous avez cité était un cas britannique. Étant donné que la question a été étiquetée États-Unis, vous voudrez peut-être mentionner explicitement que vous citiez un cas britannique (ou si toute la réponse est basée sur la loi britannique, dites-le).
@cpast J'ai ajouté une référence au cas américain.
Assurez-vous de mentionner que l'affaire américaine est une affaire de droit d'État. Il n'y a pas de common law fédérale (bien que les juristes puissent couper les cheveux). Notez également que s'il y a la réclamation pour négligence, il y a une question plus large de ** qualité pour agir **, c'est-à-dire qui a le droit de présenter la réclamation pour commencer et il y a aussi la question des ** dommages **. Ainsi, dans une réclamation pour négligence, tous sont requis ** (1) ** obligation; ** (2) ** violation; ** (3) ** causalité; et ** (4) ** dommages-intérêts, et ** (5) ** le demandeur doit avoir qualité pour intenter une action.
Cette réponse semble être un peu à l'envers - comment se fait-il que ce soit la faute du chercheur si les programmeurs de l'entreprise qui a écrit le code ne peuvent pas compter et / ou taper? Par exemple. De même, la plupart des logiciels sont livrés sans garantie; si le fabricant a spécifiquement décidé de fournir une garantie, ce n'est pas de votre faute s'il l'a fait sans s'assurer que son code n'est pas sujet à ces erreurs simples ou à d'autres erreurs simples.
@cnst: ce n'est pas une faute, c'est une faute d'enseigner aux autres comment exploiter un logiciel qui peut être utilisé pour nuire. De plus, il n'est pas vrai que la plupart des logiciels ne sont pas garantis: au moins la plupart des logiciels d'entreprise le font.
@kevin Je ne suis pas d'accord pour dire qu'enseigner aux autres comment utiliser un ensemble de compétences est une erreur. Tout comme montrer à quelqu'un comment utiliser une arme à feu ou un marteau ne fait pas d'eux des criminels. C'est ce qu'ils font avec cette arme ou ce marteau qui constituerait un acte criminel.
@DigitalFire Je suis d'accord. Une distinction doit être faite entre apprendre à quelqu'un comment utiliser une arme à feu et laisser une arme armée sur un bureau. Comme je l'ai dit, la vulnérabilité * peut * être divulguée publiquement sur CVE.
Kevin, Dead link "Voici une lecture intéressante sur Motorola prenant les choses en main après avoir découvert une vulnérabilité sur le système Xerox CP-V et Xerox n'a pas corrigé le problème." Je veux lire ça):
@LateralTerminal Je l'ai trouvé sur un cache Web et je l'ai rendu disponible sur coller bin.
Kevin, est-ce une histoire vraie? Même si ce n'est pas le cas, j'adore ça.
@kevin C'est plutôt bien.
«Vous avez le devoir de diligence d'éviter les actes ou omissions dont vous pouvez raisonnablement prévoir qu'ils sont susceptibles de blesser votre voisin» C'est une présentation trompeuse des citations. Donoghue n'a pas conclu qu'il y avait une obligation générale de diligence d'éviter la négligence, elle a conclu que * si * une obligation de diligence existe, alors cette obligation peut être violée par négligence. De plus, si un hacker utilise sa divulgation pour faire un exploit, les actions du hacker sont clairement une cause intermédiaire. En outre, toute conclusion de responsabilité impliquerait le premier amendement.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...