Bug software: quando un difetto diventa una vulnerabilità

Un bug è un difetto nel comportamento di un programma: fa qualcosa di diverso da ciò per cui era stato scritto. La maggior parte dei bug è irrilevante dal punto di vista della sicurezza — un allineamento sbagliato, un totale calcolato male, una funzione che si blocca in una condizione improbabile. Sono problemi di qualità, e vengono corretti quando qualcuno li segnala.

Una minoranza di quei difetti è però qualcosa di diverso. Un bug diventa una vulnerabilità quando permette a qualcuno di ottenere un risultato che il programma non intendeva concedere: leggere un dato che non gli appartiene, eseguire un comando, entrare senza credenziali valide. La differenza non sta nella gravità dell’errore di programmazione, sta in cosa quell’errore rende possibile.

1. Quando un bug diventa una vulnerabilità
2. Perché lo stesso bug pesa in modo diverso
3. Come si trovano quelli che contano
4. I difetti che nessun elenco segnala
5. Che cosa fare se il software non lo scrivete voi

Quando un bug diventa una vulnerabilità

Il passaggio da difetto a vulnerabilità dipende da una sola condizione: che il comportamento inatteso sia raggiungibile e controllabile da chi non dovrebbe. Un errore che si manifesta solo con dati impossibili da inviare dall’esterno resta un problema di qualità. Lo stesso errore, se innescabile modificando un parametro in una richiesta, è una porta.

Le famiglie ricorrenti sono poche e si somigliano da decenni. Ci sono i difetti nella gestione degli input, in cui il programma tratta come istruzione qualcosa che era solo un dato — è il meccanismo che sta dietro alle iniezioni di codice. Ci sono i difetti nella verifica dei permessi, in cui l’applicazione controlla se siete autenticati ma non se quel particolare dato è vostro. Ci sono i difetti nella gestione della memoria, che consentono di far eseguire istruzioni arbitrarie al programma. E ci sono i difetti logici, dove ogni singola operazione è corretta ma la sequenza permette un risultato che nessuno aveva previsto.

Quando uno di questi difetti viene reso pubblico riceve un identificativo e una descrizione, e a quel punto diventa una risorsa disponibile a chiunque, non un segreto di chi l’ha scoperto. Se non esiste ancora una correzione si parla di vulnerabilità zero-day, e il codice che la sfrutta è un exploit.

Perché lo stesso bug pesa in modo diverso

Qui sta il punto che sfugge più spesso, e che rende inutilizzabili gli elenchi di avvisi ricevuti dai produttori: la gravità di un difetto non è una proprietà del difetto, è una proprietà del contesto in cui si trova.

Lo stesso difetto, due contesti. La gravità non è una proprietà del bug ma delle condizioni in cui si trova: è il motivo per cui un punteggio numerico non basta a stabilire le priorità.

Lo stesso componente vulnerabile può essere irrilevante o critico a seconda di tre elementi. Se è raggiungibile da internet o soltanto da una rete interna. Se la funzione difettosa è effettivamente utilizzata dalla vostra applicazione, perché una libreria può essere presente e mai invocata nel punto che conta. E con quali privilegi il programma è in esecuzione, perché lo stesso accesso ottenuto vale in modo diverso se il processo gira con permessi limitati o come amministratore.

È il motivo per cui il punteggio numerico attribuito a una vulnerabilità è un punto di partenza e non una risposta. Un difetto classificato come critico in astratto può essere non sfruttabile nel vostro assetto; uno di gravità media su un componente esposto e con exploit in circolazione può essere il problema più urgente che avete. Su come si costruisce un ordine sensato abbiamo scritto parlando di come prioritizzare le vulnerabilità e di come si valuta il livello di gravità.

Come si trovano quelli che contano

I difetti già noti si individuano confrontando ciò che avete installato con gli elenchi pubblici di vulnerabilità. È un’operazione automatizzabile, ed è la parte che uno strumento di scansione svolge bene: restituisce l’elenco dei componenti con versioni affette, e su un’applicazione web di media complessità produce facilmente centinaia di voci.

Il limite di quell’elenco è duplice. Contiene falsi positivi, cioè segnalazioni che nel vostro caso non si applicano, e non contiene niente su ciò che è stato scritto su misura. Uno strumento automatico riconosce le vulnerabilità che qualcun altro ha già trovato altrove; per quelle che esistono solo nella vostra applicazione non ha nessun riferimento con cui confrontarsi.

La conseguenza pratica è che le due attività servono a scopi diversi e non si sostituiscono. La prima vi dice se state usando componenti con difetti noti, e va ripetuta con regolarità perché l’elenco pubblico cresce ogni giorno: quando ne emerge uno che vi riguarda, la finestra utile per intervenire si misura in ore, come abbiamo visto parlando delle patch delle applicazioni web.

I difetti che nessun elenco segnala

La seconda categoria è quella che in un’applicazione aziendale pesa di più, e non compare in nessun avviso di sicurezza perché riguarda soltanto voi.

Sono i difetti nelle logiche di autorizzazione, dove modificando l’identificativo in una richiesta si accede al documento di un altro cliente. Sono le funzioni raggiungibili da profili che non dovrebbero vederle, perché il controllo è stato messo sull’interfaccia e non sul lato server. Sono le sequenze di operazioni che consentono di ottenere uno stato non previsto — un ordine confermato senza pagamento, uno sconto applicato due volte, una pratica approvata saltando un passaggio. Non sono errori di codice in senso stretto, sono difetti di progettazione, ed è la ragione per cui la classificazione OWASP dedica loro diverse categorie distinte.

Trovarli richiede di usare l’applicazione con l’intenzione di farla sbagliare: capire cosa fa, ipotizzare dove il controllo potrebbe mancare, provare. È un’attività di ragionamento, non di confronto con un elenco, e nessuno strumento la svolge perché non esiste un riferimento noto contro cui verificare.

Che cosa fare se il software non lo scrivete voi

La maggior parte delle aziende italiane non sviluppa i propri applicativi: li acquista, li fa personalizzare o li riceve in gestione da un fornitore. È una condizione che cambia le leve disponibili ma non elimina la responsabilità, perché il servizio verso i vostri clienti resta vostro anche quando il codice è di qualcun altro.

Le tre leve praticabili sono queste. La prima è contrattuale: chiedere al fornitore quali verifiche di sicurezza svolge sul proprio prodotto, con quale periodicità e con quali esiti, e chiedere che la risposta sia datata. La seconda è tecnica: far verificare l’applicazione da un soggetto terzo, che è l’unico modo di sapere qualcosa che il fornitore non vi ha detto — e che spesso il fornitore stesso non sa, perché nessuno ha guardato. La terza è organizzativa: stabilire cosa accade quando un difetto viene individuato, cioè entro quanto il fornitore è tenuto a correggerlo e chi verifica che l’abbia fatto.

L’ultima è quella che manca più spesso. Segnalare una vulnerabilità a un fornitore senza un termine concordato e senza una riverifica successiva significa, nella pratica, non averla segnalata.

In conclusione

Non tutti i bug sono un problema di sicurezza, e non tutti i bug di sicurezza sono un problema per voi. Quello che distingue le due categorie non è la gravità dell’errore ma la raggiungibilità: chi può innescarlo, da dove, e cosa ottiene se ci riesce.

È il motivo per cui la domanda utile su un’applicazione non è quanti difetti contiene, ma quali di essi qualcuno potrebbe effettivamente usare per arrivare ai vostri dati. La risposta non si ricava da un elenco di versioni: si ricava provando.