Come divulgare una vulnerabilità della sicurezza in modo etico? Ho sentito che ci sono varie scuole di pensiero su questo argomento. Mi piacerebbe conoscere i pro / contro di ciascuno.
Dovresti informare gli sviluppatori in privato in modo che abbiano la possibilità di risolverlo. Dopodiché, se e quando diventi pubblico con la vulnerabilità, dovresti concedere allo sviluppatore abbastanza tempo per risolvere il problema e chiunque ne sia esposto abbastanza tempo per aggiornare i propri sistemi. Personalmente, consentirei allo sviluppatore di fare l'annuncio in un bollettino sulla sicurezza nella maggior parte dei casi piuttosto che annunciarlo io stesso. Per lo meno, aspetterei la conferma che la vulnerabilità è stata risolta. Se hai tempo e hai accesso al codice sorgente, potresti anche fornire una patch.
Personalmente penso che la divulgazione responsabile sembri il modo migliore per andare da un punto di vista etico e ha funzionato bene per Dan Kaminsky che rivela i dettagli della vulnerabilità dell'avvelenamento della cache DNS. Ma tutto dipende molto dalla società o dal gruppo con cui hai a che fare e anche dalla base di utenti che influenzerà.
@VirtuosiMedia fa un ottimo lavoro nel delineare la "Divulgazione responsabile".
Aggiungerei due punti:
Questo è un argomento complesso. Sono stato coinvolto nella divulgazione del bug di rinegoziazione TLS un paio di anni fa e, credetemi, abbiamo cercato di essere "responsabili", ma alla fine siamo riusciti principalmente a far incazzare tutti intorno a noi e (forse) a ritardare il rilascio effettivo della correzione. Non per dire che la notifica del fornitore sia necessariamente negativa, ma solo che è davvero facile farsi sorprendere e finire per causare tanto danno quanto bene, o peggio.
Nel nostro caso, è stata eseguita un'azione dell'IETF ( RFC 5746) per risolvere il problema, e anche se avevamo una bozza Internet pronta il giorno in cui è trapelata, il lavoro effettivo di discussione e decisione sulla soluzione ha richiesto circa altri tre mesi e non iniziare davvero sul serio fino a quando non è avvenuta la divulgazione.
Comunque, questa non è una risposta alla tua domanda, ma è una delle storie di divulgazione più interessanti di cui sono a conoscenza. Maggiori informazioni su quella storia nel discorso di apertura dello ShmooCon 2010 che ho fatto con Marsh Ray, che ha scoperto il problema.
In genere, dipende dalla risposta del fornitore. Una buona pratica è quando un ricercatore di sicurezza informa il fornitore sulla vulnerabilità, quindi durante la conversazione si parla dei termini di pubblicazione di poc / exploit di questa vulnerabilità. In realtà, il ricercatore sceglie cosa fare con questa vulnerabilità: pubblicare in un secondo momento o meno. Quindi il fornitore rilascia la patch o la nuova versione del prodotto. Può essere. Ma come mostra l'esperienza - non tutti i fornitori sono così gentili. Alcuni di loro risolvono i bug in silenzio, senza informare gli utenti finali e i ricercatori, alcuni preferiscono ignorare il ricercatore. Altri cercano persino di fare causa. Ecco perché a volte l'anonimato è un modo preferibile di comunicazione iniziale con un fornitore sconosciuto.
Inoltre, vorrei ammettere che ci sono programmi di ricompensa per i bug, quelli offerti da Google, Mozilla. Inoltre, altri acquistano vulnerabilità: ZDI, iDefense, SNOsoft, in arrivo "hub di exploit" e così via. Ci sono almeno tre modi come informare il fornitore direttamente, pubblicando le informazioni sulla vulnerabilità in un elenco o tramite società di terze parti.
Se hanno un tracciatore di problemi pubblico, verifica se puoi segnalare un bug con un'etichetta "privata" o "sicurezza".
Indipendentemente dal fatto che abbiano un tracciatore di problemi, invia un'email a sicurezza @ companyname e faglielo sapere.
Se non rispondono abbastanza prontamente (vedi "Finestra di divulgazione" nell'articolo di Schneier di seguito), allora devi pensare sulla divulgazione più ampia. Cerca le mailing list su cui si nascondono accademici / professionisti della sicurezza e chiedi loro come segnalano i problemi al fornitore in questione. Potrebbero essere in grado di fare presentazioni nel posto giusto nell'organizzazione.
Se tutto ciò fallisce, leggi la parte di Schneier e pensa se la divulgazione completa sarebbe parte del problema o parte della soluzione.
Bruce Schneier fornisce un argomento per la divulgazione completa in determinate circostanze sulla base di uno standard "sii parte della soluzione, non parte del problema". Vale sicuramente la pena leggerlo.
Questo è il classico dibattito "segretezza dei bug e divulgazione completa". Ne ho già scritto in precedenza in Crypto-Gram; anche altri ne hanno scritto. È un problema complicato con sottili implicazioni in tutta la sicurezza informatica, e vale la pena discuterne di nuovo.
...
Questo flusso di informazioni libero, sia di descrizione che di prova di concetto codice, è vitale anche per la ricerca sulla sicurezza. La ricerca e lo sviluppo nella sicurezza informatica sono sbocciati negli ultimi dieci anni e gran parte di ciò può essere attribuito al movimento della divulgazione completa. La possibilità di pubblicare i risultati della ricerca, sia positivi che negativi, porta a una maggiore sicurezza per tutti. Senza pubblicazione, la comunità della sicurezza non può imparare dagli errori degli altri. Tutti devono operare con i paraocchi, facendo sempre gli stessi errori. La completa divulgazione è essenziale se vogliamo continuare a migliorare la sicurezza dei nostri computer e reti.
...
In secondo luogo, credo che sia necessario dare un preavviso al venditore. Il CERT lo ha portato all'estremo, a volte dando al fornitore anni per risolvere il problema.
...
Mi piace "essere parte della soluzione, non parte del problema" metrica. La ricerca sulla sicurezza fa parte della soluzione. Convincere i fornitori a risolvere i problemi fa parte della soluzione. Seminare paura fa parte del problema. Consegnare strumenti di attacco a adolescenti incapaci è parte del problema.