Domanda:
Responsabilità per danni negli Stati Uniti per la ricerca e la divulgazione di exploit informatici "0-day"
Digital fire
2015-05-28 17:21:49 UTC
view on stackexchange narkive permalink

Nel mondo della sicurezza IT / Programmazione, di solito le persone contattano il fornitore / proprietario di un particolare software se trovano un bug o una vulnerabilità di sicurezza e danno loro il tempo di correggerlo prima di rilasciare il bug o la vulnerabilità per il controllo / la consapevolezza del pubblico. Questo di solito è una cortesia, a meno che tu non sia vincolato da un contratto. Ma come richiesto in If I Find or Create a 0day: cosa succede se trovo una vulnerabilità in un software ampiamente utilizzato?

Posso essere ritenuto responsabile per i danni se rilascio al pubblico il codice "Proof of Concept" senza dare al fornitore il tempo di patchare e aggiornare adeguatamente il suo codice vulnerabile?

AGGIORNAMENTO: Dopo aver discusso di questa domanda con alcuni colleghi, Mi sono reso conto che ho bisogno di essere un po 'più specifico con la domanda: i ricercatori di sicurezza di solito lavorano con il fornitore per provare e correggere (correggere) l'errore / vulnerabilità. Se dopo sufficiente (30 giorni?) Il tempo è trascorso e il fornitore non ha corretto il codice, viene rilasciata pubblicamente una divulgazione completa.

Posso essere ritenuto responsabile per i danni causati dopo il rilascio di un codice "Proof of Concept" se il software / fornitore è open source? Cosa succede se il fornitore / software è closed source?

Una risposta:
#1
+14
kevin
2015-05-28 18:53:45 UTC
view on stackexchange narkive permalink

Puoi essere ritenuto responsabile per i danni? In Tort Law, sì.

Supponiamo che qualcuno abbia sviluppato un virus basato sul tuo codice. Il virus ha causato milioni di dollari di danni. Il querelante (fornitore di software) può sostenere che:

  1. Hai un dovere di diligenza

per evitare atti o omissioni che puoi ragionevolmente prevedere potrebbero danneggiare il tuo vicino

Donoghue v. Stevenson (1932) (Regno Unito)

Il concetto di Duty of Care si trova anche nella legge statunitense, ad esempio in MacPerson v. Buick Motor Co. (1916) , che stabiliva che negligenza non richiede un contratto .

  1. Violazione del dovere: una persona ragionevole può prevedere che la "prova del concetto" possa causare danni. L'atto di rilascio del codice, quindi, non è all'altezza dello standard previsto. Se sei un professionista IT, sarà difficile difendere questo punto.
  2. Esiste una relazione di causalità tra il tuo codice rilascio e il danno risultante.

  3. Sei responsabile per negligenza”.

  4. Danno: è probabile che gli utenti facciano causa al fornitore del software per le loro perdite. Il fornitore di software ti farà quindi causa, poiché a causa tua, il fornitore di software deve compensare i suoi clienti.

Questo, ovviamente, dipende da cosa hai rilasciato esattamente al pubblico. Ad esempio, se è necessario uno sforzo significativo per convertire la tua "prova di concetto" in un vero e proprio exploit e hai fornito una soluzione alternativa per evitare questa vulnerabilità, puoi difenderti sostenendo che il collegamento di causa ed effetto è troppo .


Quindi devo mantenere privato il rapporto? E se il software fosse open source?

Non proprio. Dovresti prendere misure ragionevoli per assicurarti che la tua "prova di concetto" non sia un vero e proprio exploit e un hacker ha bisogno di molto tempo per sviluppare un software dannoso funzionante. CVE è una piattaforma in cui le vulnerabilità sono condivise pubblicamente.


E se hai concesso al fornitore un tempo ragionevole per correggere la vulnerabilità?

Non importa (per te) se il venditore ha avuto il tempo di riparare la vulnerabilità. È importante per il venditore, perché se succede qualcosa in seguito, il venditore è responsabile di conoscere il problema con largo anticipo e non ha assegnato le risorse appropriate per correggere il problema.

Per dimostrare che esiste una vulnerabilità non esiste richiedono istruzioni su come utilizzare questa vulnerabilità. Ad esempio, puoi registrare un video che mostra gli effetti dell'hacking.


Qui (Wayback Machine; il link originale è morto) è una lettura interessante su Motorola che prende in esame la situazione le proprie mani dopo aver scoperto una vulnerabilità nel sistema Xerox CP-V e Xerox non ha risolto il problema.

Ho aggiornato la domanda. Credo che la risposta sarebbe applicabile solo a una situazione in cui la vulnerabilità è in un software / hardware "closed source".
Il caso che hai citato era un caso del Regno Unito. Poiché la domanda è stata contrassegnata come Stati Uniti, potresti voler menzionare esplicitamente che stavi citando un caso nel Regno Unito (o se l'intera risposta è basata sulla legge britannica, dillo).
@cpast Ho aggiunto un riferimento al caso degli Stati Uniti.
Assicurati di menzionare che il caso degli Stati Uniti è un caso di diritto statale. Non esiste una legge federale di diritto comune (sebbene gli studiosi di diritto possano dividere i capelli). Si noti inoltre che, sebbene vi sia la richiesta di risarcimento per negligenza, vi è una questione più ampia di ** stare in piedi **, cioè chi ha il diritto di intentare un'azione per iniziare e c'è anche la questione del ** risarcimento **. Quindi in una richiesta di negligenza tutti sono tenuti a ** (1) ** dovere; ** (2) ** violazione; ** (3) ** nesso di causalità; e ** (4) ** risarcimento e ** (5) ** l'attore deve essere legittimato a presentare il reclamo.
Questa risposta sembra essere un po 'arretrata: come mai è colpa del ricercatore se i programmatori dell'azienda che ha scritto il codice non sanno contare e / o digitare? Per esempio. off-by-one ecc. Allo stesso modo, la maggior parte del software viene fornita senza garanzia; se il produttore ha deciso specificamente di fornire la garanzia, non è colpa tua se lo ha fatto senza assicurarsi che il proprio codice non sia soggetto a questi errori o altri errori diretti.
@cnst: non è una colpa, è un errore insegnare agli altri come sfruttare un software che può essere usato per nuocere. Inoltre, non è vero che la maggior parte del software viene fornita senza garanzia: almeno la maggior parte del software aziendale lo fa.
@kevin Non sono d'accordo sul fatto che insegnare agli altri come utilizzare un set di abilità sia sbagliato. Proprio come mostrare a qualcuno come usare una pistola o un martello non li rende criminali. È quello che fanno con quella pistola o martello che costituirebbe un atto criminale.
@DigitalFire Sono d'accordo. Bisogna fare una distinzione tra insegnare a qualcuno come usare una pistola e lasciare una pistola armata su una scrivania. Come ho detto, la vulnerabilità * può * essere divulgata pubblicamente su CVE.
Kevin, Dead link "Ecco una lettura interessante su Motorola che prende in mano la situazione dopo aver scoperto una vulnerabilità nel sistema Xerox CP-V e Xerox non ha risolto il problema." Voglio leggerlo):
@LateralTerminal L'ho trovato su una cache web e l'ho reso disponibile su paste bin.
Kevin, è una storia vera? Anche se non lo è, lo adoro.
@kevin Questo è abbastanza buono.
"Hai il dovere di diligenza di evitare atti o omissioni che puoi ragionevolmente prevedere potrebbero danneggiare il tuo vicino" Questa è una presentazione fuorviante di citazioni. Donoghue non ha riscontrato che ci sia un dovere di diligenza generale per evitare la negligenza, ha scoperto che * se * esiste un dovere di diligenza, allora quel dovere può essere violato per negligenza. Inoltre, se un hacker utilizza la propria divulgazione per fare un exploit, le azioni dell'hacker sono chiaramente una causa intermedia. Inoltre, qualsiasi accertamento di responsabilità implicherebbe il Primo Emendamento.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...