Come divulgare una vulnerabilità della sicurezza in modo etico?

Dovresti lasciare che lo sviluppatore (i) sappia in privato in modo che abbia la possibilità di risolverlo. Dopodiché, se e quando si rende pubblica la vulnerabilità, è necessario consentire allo sviluppatore di avere il tempo sufficiente per risolvere il problema e a chi ne è esposto abbastanza tempo per aggiornare i propri sistemi. Personalmente, consentirò allo sviluppatore di fare l'annuncio in un bollettino sulla sicurezza nella maggior parte dei casi piuttosto che annunciarlo da solo. Per lo meno, aspetterei la conferma che la vulnerabilità è stata corretta. Se hai tempo e hai accesso al codice sorgente, puoi anche fornire una patch.

Personalmente ritengo che Divulgazione responsabile sembra essere il modo migliore per passare da un punto di vista etico e ha funzionato bene per Dan Kaminsky rivelando i dettagli della vulnerabilità di avvelenamento della cache DNS. Ma tutto dipende molto dalla compagnia o dal gruppo con cui si ha a che fare e anche dalla base di utenti che influenzerà.

@VirtuosiMedia fa un ottimo lavoro nel delineare "Divulgazione responsabile".

Vorrei aggiungere due punti:

• Lavora con il venditore (se puoi), per assicurarti che lo comprenda pienamente e non emetta una patch semicotta.
• Se il venditore non ti tiene conto o ti ignora, continua a provare. Tuttavia, se affermano che non è una vulnerabilità, vai avanti e pubblica. Il più strong possibile. Se hanno promesso di risolvere, ma non farlo, prova a ottenere una risposta da loro, insieme a una tempistica definitiva a cui si impegnano. Ad un certo punto, se continuano a posticipare, alla fine potresti voler dire loro che pubblicherete comunque, e poi dargli un po 'di tempo per risolverlo (ma breve e limitato).

Questo è un diavolo di un argomento complesso. Sono stato coinvolto nella divulgazione del bug di rinegoziazione TLS un paio di anni fa, e credetemi, abbiamo cercato molto duramente di essere "responsabili", ma alla fine siamo riusciti principalmente a far incazzare chiunque intorno a noi e (forse) a ritardare l'effettiva versione della correzione. Per non dire che la notifica del venditore è necessariamente negativa, solo che è davvero facile farsi scodinzolare e finire con l'avere più danni, o peggio.

Nel nostro caso, è stata intrapresa un'azione IETF ( RFC 5746 ) per risolvere il problema, e anche se avevamo un progetto Internet pronto per il giorno in cui è trapelato, l'effettivo lavoro di discussione e decisione sulla soluzione è durato circa altri tre mesi e non è iniziato sul serio fino a quando la divulgazione non si è svolta.

Ad ogni modo, questa non è una risposta alla tua domanda, ma è una delle storie di divulgazione più interessanti di cui sono a conoscenza. Altro su quella storia nella keynote di ShmooCon 2010 l'ho fatto con Marsh Ray, che ha scoperto il problema.

Generalmente, dipende dalla risposta del venditore. Una buona pratica è quando il ricercatore di sicurezza informa il venditore sulla vulnerabilità, quindi durante la conversazione parli dei termini di pubblicazione di poc / exploit di questa vulnerabilità. In realtà, il ricercatore sceglie cosa fare con questa vulnerabilità - pubblica più tardi o meno. Quindi il venditore rilascia patch o nuova versione del prodotto. Può essere. Ma, come dimostra l'esperienza, non tutti i venditori sono così gentili. Alcuni di essi risolvono i bug in modo silenzioso, senza informare gli utenti finali e i ricercatori, alcuni preferiscono ignorare il ricercatore. Altri ancora cercano 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 dei programmi di ricompensa per i bug bounty: quelli offerti da Google, Mozilla. Inoltre, altri acquistano vulnerabilità: ZDI , iDefense , SNOsoft , arrivo "exploit hub", ecc. Quindi, ci sono almeno tre modi per informare il fornitore - direttamente, pubblicando le informazioni sulle vulnerabilità in qualche elenco o tramite società di terze parti.

Se hanno un tracker di problemi pubblici, vedi se puoi segnalare un bug con un'etichetta "privata" o "sicurezza".

Indipendentemente dal fatto che abbiano un tracker di problemi, email security@ companyname e fagli sapere.

Se non rispondono abbastanza tempestivamente (vedi "Finestra di divulgazione" nell'articolo di Schneier in basso), allora devi pensare a divulgarlo più diffusamente. Cerca le mailing list in cui gli accademici / professionisti della sicurezza si nascondono e chiedi loro come riportano i problemi al fornitore in questione. Potrebbero essere in grado di presentare le introduzioni nel posto giusto all'interno dell'organizzazione.

Se tutto ciò non funziona, leggi il bit di Schneier e pensa se la divulgazione completa sarebbe parte del problema o parte della soluzione.

Bruce Schneier fornisce un argomento per completa divulgazione in determinate circostanze basate su "fa parte del soluzione, non parte del problema "standard. Vale sicuramente la pena leggere.

This is the classic "bug secrecy vs. full disclosure" debate. I've written about it previously in Crypto-Gram; others have written about it as well. It's a complicated issue with subtle implications all over computer security, and it's one worth discussing again.

...

This free information flow, of both description and proof-of-concept code, is also vital for security research. Research and development in computer security has blossomed in the past decade, and much of that can be attributed to the full-disclosure movement. The ability to publish research findings -- both good and bad -- leads to better security for everyone. Without publication, the security community can't learn from each other's mistakes. Everyone must operate with blinders on, making the same mistakes over and over. Full disclosure is essential if we are to continue to improve the security of our computers and networks.

...

Second, I believe in giving the vendor advance notice. CERT took this to an extreme, sometimes giving the vendor years to fix the problem.

...

I like the "be part of the solution, not part of the problem" metric. Researching security is part of the solution. Convincing vendors to fix problems is part of the solution. Sowing fear is part of the problem. Handing attack tools to clueless teenagers is part of the problem.