Il concetto, in sintesi
- la full disclosure è la scelta compiuta da chi ricerca vulnerabilità di sistemi operativi e applicazioni, di renderne integralmente noti i risultati.
- A seconda della tipologia delle informa- zioni rilasciate e delle tempistiche adottate, si possono configurare diversi livelli di responsa- bilità per lo scopritore dei bug
- La scoperta di una vulnerabilità causata da una grave negligenza del produttore può provocare, a carico di quest’ultimo, l’apertura di procedimenti penali e l’attivazione di class action.
- Prima di rendere integralmente nota una vulnerabilità è opportuno segnalarla al pro- duttore del software e alle forze di polizia.
Il concetto, in teoria
1. La definizione
Il termine full disclosure indica la scelta “filosofica” di un programmatore o sistemista che decide rendere libe- ramente e gratuitamente disponibili le informazioni su vulnerabilità o difetti di progettazione/implementazione rinvenuti analizzando un dato softwa- re senza avere accesso al relativo codice sorgente.
2. Full disclosure e penetration-test abusivi
Come si è accennato nel numero precedente, la ricerca di vulnerabilità è inconciliabilmente diversa dall’eseguire penetration test non richiesti su sistemi di terze parti. Non rientra, quindi, nell’ambito della full disclosure il tentati vo di “bucare” un server per poi vendere la soluzione alla vittima. Questo si chiama “estorsione” ed è un compor tamento sanzionato gravemente dal codice penale.
3. Le responsabilità del bug hunter
Venendo al merito specifico delle responsabilità legate alla full disclosure è necessario distinguere due ambiti. Il primo riguarda le condizioni che ren- dono questa attività lecita. Nella misura in cui la ricerca è compiuta rispet- tando la legge sul diritto d’autore (e in particolare le limitazioni sul reverse engineering), essa non è automaticamente illegale.
Quando invece il bug hunter decide di mettere in circolazione la “ricetta” per costruire l’exploit (il software che consente di sfruttare concretamente la
vulnerabilità), o addirittura l’exploit stesso, le cose possono essere diverse.
Non è infatti la stessa cosa diffondere subito il dettaglio di una vulnerabilità e senza avere dato al produttore il tempo di predisporre un rimedio, o invece segnalare il problema e attende- re un periodo di tempo ragionevole prima di rendere pubblica la notizia.
Dal punto di vista tecnico ognuna delle scelte di cui sopra ha una sua giustificazione. Ma in termini di re- sponsabilità quantomeno civilisitica le differenze ci sono e sono anche sostan- ziali. Pertanto è teoricamente possibile che il bug hunter possa essere portato in causa per rispondere dei danni che ha provocato, anche se non volontaria- mente, con la messa in circolazione del risultato dei suoi studi.
4. Le responsabilità dei produttori del software difettoso
La scoperta di una vulnerabilità, specie se collegata all’esistenza di fun- zioni non documentate (cioè “nasco ste” dal produttore), è fonte di una precisa responsabilità giuridica anche per chi ha realizzato e diffuso il soft- ware difettoso. Le clausole delle licen ze d’uso che esonerano il produttore da qualsiasi responsabilità sono, infatti, nulle. La legge italiana stabilisce in proposito che le limitazioni contrattua- li di responsabilità non valgono in caso di “dolo” (cioè di bug noto al produttore, ma da questi nascosto ai clienti) e di “colpa grave” (difetto ignoto anche al produttore, per sua negligenza o impe- rizia non scusabile).
Nonostante le gravi responsabilità dell’industria del software nella crea- zione di una infrastruttura di comuni- cazione geneticamente compromessa, i proprietari dei prodotti di cui si è scoperta la vulnerabilità non vedono di buon occhio l’attività di ricerca delle vulnerabilità. E, pur essendo a volte costretti a “fare buon viso a cattivo gioco”, sono sempre in attesa dell’oc- casione per agire legalmente contro lo scopritore del bug.
Di regola, questo accade con l’in- vio di una lettera di cease and desist, con la quale gli avvocati dell’azienda inti- mano al ricercatore di cessare ogni attività di studio su un certo pro-
gramma, di rimuovere ogni informa- zione eventualmente diffusa, e di evi- tare anche solo di parlare dei prodotti dell’azienda “parte lesa”.
E’ anche vero, tuttavia, che gli stessi produttori conoscono bene gli effetti di un’azione legale. Con partico- lare riferimento all’inevitabile pubbli- cazione di informazioni anche relative al modo in cui (non) è stato collaudato il software o l’apparato e che sarebbe meglio non far circolare. Il che po- trebbe trasformarli da “carnefici” in “vittime” di azioni giudiziarie (come class action o, nei casi più gravi, addirittura procedimenti penali).
5. Conclusioni
Benchè (non sempre) ispirata da “buoni sentimenti” la full disclosure asso- luta, che non tiene conto delle conse- guenze della diffusione indiscriminata di determinate informazioni, può esse- re fonte di responsabilità per danni a carico dello scopritore di bug. E’ sicu- ramente preferibile, e dal punto di vista giuridico più coerente, adottare una procedura di diffusione graduale delle informazioni. In primo luogo dovrebbe essere avvisato l’autore del software e, se la vulnerabilità è critica, anche le forze di polizia (Nucleo anti- crimine tecnologico della Guardia di finanza, oppure Polizia delle comuni- cazioni). Solo successivamente, quan- do è stata rilasciata la patch o il produt- tore del software non ha inteso realiz- zarla, si potrebbe procedere alla diffu- sione pubblica della notizia e del rela- tivo codice informatico. Perché o la falla è stata chiusa o, in caso di inerzia della software house, il pubblico ha dirit- to di sapere.
Il concetto, in pratica
- Nell’attività di bug hunting è essen- ziale poter dimostrare di non avere violato diritti di proprietà intellettuale.
- Se si decide di rendere pubblica la sco- perta del bug sarebbe opportuno contattare innanzi tutto il proprietario del software.
- Bisogna evitare, a qualsiasi costo, che il contatto di cui al punto precedente venga scambiato per un tentativo di estorsione.
Possibly Related Posts:
- Qual è il significato geopolitico del sistema operativo Huawei Harmony OS Next
- TeamLab Planets: da Tokyo la fuga verso i mondi della mente
- Chi ci protegge dal dossieraggio tecnologico?
- Webscraping e Dataset AI: se il fine è di interesse pubblico non c’è violazione di copyright
- Perché Apple ha ritirato la causa contro la società israeliana dietro lo spyware Pegasus?