L’Antefatto
Il giorno primo gennaio 2011 viene dato l’ok per l’inclusione di una porzione di codice relativa ad una feature del protocollo TLS all’interno della libreria OpenSSL. Tale feature era un’estensione del protocollo volta a consentire a due server TLS di comunicare tra loro dei dati e verificare che la connessione tra i due fosse stabile. Tale estensione fu standardizzata nel febbraio 2012, ovvero più di un anno dopo l’inclusione del codice, nel RFC 6520.
In quella porzione di codice però, per un malaugurato errore, non era stato inserito un controllo di congruenza tra la quantità di dati inviata e quella richiesta.
7 aprile 2014
Viene diramato il comunicato che una nuova versione di OpenSSL è stata rilasciata e che gli utenti della libreria sono caldamente invitati ad effettuare l’upgrade per mitigare gli effetti della vulnerabilità indicata dal codice CVE-2014-0160 (Heartbleed).
Dal 8 aprile in poi
Viene aperto il sito ufficiale di Heartbleed [heartbleed.org] e il panico si diffonde nella rete: siti e blog tecnici disquisiscono sulle possibili implicazioni del bug Heartbleed mentre nel resto dei media si diffonde l’allarme sulle possibili fughe di password e altri segreti.
Le conseguenze
Il bug Heartbleed ha avuto un notevole impatto, specialmente emotivo, ma se cerchiamo materiale in merito in lingua italiana troviamo ben poco… Anche la pagina di Wikipedia in merito è decisamente scarna…
Per ovviare un po’ a questa lacuna (e perché lo stesso blog degli GNUrants è ancora molto scarno) vi esporrò (al meglio delle mie capacità) quello che ho appreso sul bug in questione e sul suo impatto dal punto di vista tecnico per poi passare ad esporre alcune considerazioni sul come si è arrivati a tutto questo e su quali passi ritengo si debbano prendere per ridurre la probabilità che si verifichi di nuovo una simile situazione (alcuni di questi passi sono già stati intrapresi, altri richiedono tempi molto più lunghi).
Giochiamo con l’input
Cominciamo col catalogare Heartbleed e col descrivere di che genere di vulnerabilità si tratta…
Per prima cosa dobbiamo studiare un po’ la feature Heartbeat del protocollo TLS e capire cosa fa e in questo ci viene in aiuto Randall di XKCD (immagine omessa per questioni di Copyright): in breve l’Heartbeat è un meccanismo per chiedere ad un server TLS se è ancora vivo in una maniera simile al caro buon vecchio ICMP Echo Request/Echo Response. Il problema è che, nell’implementazione di OpenSSL è possibile forgiare un pacchetto che abbia un messaggio breve ma che richieda una risposta lunga e la libreria, invece di ignorare tale richiesta malformata, provvederà ad allocare abbastanza spazio nella memoria per mandare indietro la risposta.
“E questo è un problema?” E’ un problema nel momento in cui in quella porzione di memoria ci sono informazioni sensibili che non verranno sovrascritte ma inviate a chi ha fatto la richiesta.
“Di che informazioni stiamo parlando?” In generale di qualsiasi informazione che sia presente nello spazio di memoria a disposizione di OpenSSL, il che può voler dire cose come:
Andiamo più in profondità
Ok, è venuto il momento tanto atteso: adesso faremo un salto dentro al codice sorgente e vedremo un po' più in dettaglio cosa ha causato tutto questo pasticcio. Come riferimento userò la patch rilasciata dai maintainer del progetto OpenBSD e la ragione è duplice:
E adesso, finalmente, vediamo il codice C:
Ok, questa è una porzione di libreria che è stata tolta, il commento ci dà un indizio: “Read type and payload length first”.
Non abbiamo tutto il codice sorgente sotto gli occhi, ma è ragionevole supporre che p sia un puntatore ai dati del pacchetto TLS Heartbeat appena ricevuto e siccome il tipo è indicato nel RFC come intero a 8 bit (ma può assumere come valori solo 1 o 2) il nostro programmatore ha deciso di fare in fretta e fare due cose con un'unica istruzione: leggere il valore (salvandolo in hbtype) e portarsi al campo successivo con l'uso dell'operatore di post-incremento (il “++” dopo “p”) il “*” davanti a “p” è necessario perché altrimenti invece del valore leggeremmo l'indirizzo di memoria in cui questo si trova (e non ce ne faremmo nulla). Fin qui nulla di strano, si tratta di una pratica standard nella programmazione C anche se è malvista perché riduce la leggibilità del codice.
La linea di codice successiva è una chiamata alla funzione n2s: anche qui non abbiamo tutto il codice, ma possiamo ricavare dal contesto e dai parametri che gli vengono passati che quella funzione non faccia altro che leggere la lunghezza del messaggio di Heartbeat dal pacchetto e salvare tale lunghezza in payload. Notate bene: questa è la lunghezza dichiarata, non necessariamente la lunghezza reale del messaggio. Tenete bene a mente che non abbiamo alcuna garanzia che quello che ci viene detto corrisponda a verità e che il diavolo sta nei dettagli.
L'ultima riga serve a salvare un puntatore al messaggio vero e proprio in “pl”.
Segue una porzione che è rimasta invariata e che si occupa di controllare se è stata registrata una callback e di chiamare tale callback: le ragioni per cui si vuole poter chiamare una funzione esterna quando si comincia a processare un pacchetto possono essere le più varie, ma di solito lo si fa per avere un log per questioni di debug.
Dopo una sezione di codice aggiunto (che ignoreremo) abbiamo le righe seguenti:
Allora, vediamo un po' cosa abbiamo qui… Questa riga qui è la radice del Male:
OpenSSL è una libreria multipiattaforma, il che significa che deve girare su una gran varietà di Sistemi Operativi diversi. Alcuni di questi offrono meccanismi di protezione della memoria, altri no. Per avere una base comune gli sviluppatori di OpenSSL hanno creato una loro implementazione delle chiamate malloc e free: la prima riserva della memoria mentre la seconda la libera. Il problema di questo approccio è che, se non fai le cose per bene, puoi bypassare completamente i meccanismi che il Sistema Operativo adotta per proteggere la memoria e ridurre l’impatto che possono avere certi errori di programmazione.
La chiamata malloc fa parte della libreria standard del C e si appoggia a chiamate simili del sistema operativo per allocare (riservare) una porzione di memoria che un programma in esecuzione può utilizzare come meglio crede (anche condividendola con librerie e/o altri programmi in esecuzione). malloc può riservare aree di memoria precedentemente non utilizzate da altri programmi (bene) oppure aree di memoria già utilizzate da altri processi e da questi rese libere per il riutilizzo (male perché potrebbero ancora contenere dati) mentre OPENSSL_malloc riutilizza memoria pre-allocata dalla libreria stessa (molto male) e mantiene una sua lista delle allocazioni per poter far funzionare OPENSSL_free (la funzione che si occupa di liberare la memoria per il riutilizzo). Facendo così OpenSSL bypassa i meccanismi di ASLR (Address Space Layout Randomization) messi in atto dal kernel del Sistema Operativo per ridurre l'impatto di certi errori di programmazione.
Una discussione completa sui meccanismi di protezione della memoria esula dallo scopo di questo articolo, ma invito il lettore a dare un'occhiata alle slide che Theo DeRaadt ha proposto al ruBSD 2013 e, per i più curiosi, all'articolo in merito ad ASLR su Wikipedia.
Quello che succede in quella porzione di codice è che il programmatore si è fidato della lunghezza dichiarata dal pacchetto e ha riservato una porzione di memoria pari a quella lunghezza. Come già detto OpenSSL gestisce per conto suo la memoria e, siccome la memoria non è infinita, riutilizza la memoria. Nella porzione di codice precedente quella memoria non viene “pulita” prima di essere utilizzata e quindi potrebbe contenere qualsiasi cosa. Inoltre non vengono fatti dei controlli che il messaggio sia lungo quanto dichiarato.
Se il messaggio è più breve del valore dichiarato quello che succede è che viene occupata solo parte della memoria allocata e il resto viene spedito così com'è al richiedente.
C'è una piccola consolazione: il campo lunghezza consente di avere un payload che può essere lungo al massimo 65536 byte e occorre indicare almeno un byte per il messaggio portando la quantità di dati leggibili a dall'attaccante a 65535 byte (64 kilobyte). La probabilità di trovare dati utili in una finestra così stretta si abbassa molto ed occorre anche essere in grado di distinguere i dati utili dalla spazzatura (e gli algoritmi di generazione delle chiavi crittografiche fanno di tutto per far apparire le chiavi stesse come dati casuali apparentemente senza capo nè coda), ma è già stato dimostrato che avendo abbastanza pazienza (si parla di milioni di tentativi) si può leggere anche la chiave privata usata da un server web per decrittare TUTTE le comunicazioni criptate.
Conclusioni
Il bug in questione ha tutta l'aria di essere finito lì a causa di una svista: la feature era nuovissima (ancora in fase di standardizzazione) e in seguito è stata poco utilizzata (pochi hanno sentito il bisogno di usare il TLS Hearthbeat quando ci sono decine di altre tecniche di High Availability disponibili) per cui pochi occhi si sono concentrati su quel codice.
Sicuramente è significativo che anche nel mondo dell'Open Source ci siano casi di feature “aggiunte e dimenticate” che ricevono poca o nessuna manutenzione. Ed è significativo che il presupposto principale dello sviluppo a sorgente aperto (molti occhi che guardano il codice si accorgono prima di certi errori) sia venuto meno nel caso di una delle librerie più utilizzate per la comunicazione sicura di pagine web, posta elettronica e una moltitudine di altri servizi.
Ci si è fidati della buona volontà e delle capacità di chi ha scritto OpenSSL (persone che meritano la stima e il rispetto di tutti quanti noi per il lavoro svolto) senza ricontrollare e così un errore fatto in buona fede è finito per avere un impatto clamoroso su tutta l'infrastruttura su cui si basa il web 2.0. Non basta che il codice sia visibile a tutti: occorre che qualcun altro oltre agli sviluppatori ci dia un'occhiata ogni tanto.
Ricette magiche non ce ne sono, ma questo pasticcio ha senz'altro portato all'attenzione di tutti le falle presenti in OpenSSL e la necessità di rimettere a posto quel codice nel suo complesso (e non solo la parte relativa al bug Heartbleed).
Moltissime aziende utilizzano OpenSSL nei loro prodotti (grazie anche alla licenza molto liberale) e alcuni dei player più grossi si sono resi conto che forse è il caso di dare qualcosa indietro a quei quattro gatti che lavorano su quel codice così importante. La mia speranza è che (oltre a beccarsi enormi quantità di trolling) lo sforzo degli sviluppatori venga premiato e che altra gente cominci a pensare che non basta sviluppare un daemon DHCP nell'init system ma che c'è anche bisogno di mantenere e controllare quello che già c'è.
In quella porzione di codice però, per un malaugurato errore, non era stato inserito un controllo di congruenza tra la quantità di dati inviata e quella richiesta.
7 aprile 2014
Viene diramato il comunicato che una nuova versione di OpenSSL è stata rilasciata e che gli utenti della libreria sono caldamente invitati ad effettuare l’upgrade per mitigare gli effetti della vulnerabilità indicata dal codice CVE-2014-0160 (Heartbleed).
Dal 8 aprile in poi
Viene aperto il sito ufficiale di Heartbleed [heartbleed.org] e il panico si diffonde nella rete: siti e blog tecnici disquisiscono sulle possibili implicazioni del bug Heartbleed mentre nel resto dei media si diffonde l’allarme sulle possibili fughe di password e altri segreti.
Le conseguenze
Il bug Heartbleed ha avuto un notevole impatto, specialmente emotivo, ma se cerchiamo materiale in merito in lingua italiana troviamo ben poco… Anche la pagina di Wikipedia in merito è decisamente scarna…
Per ovviare un po’ a questa lacuna (e perché lo stesso blog degli GNUrants è ancora molto scarno) vi esporrò (al meglio delle mie capacità) quello che ho appreso sul bug in questione e sul suo impatto dal punto di vista tecnico per poi passare ad esporre alcune considerazioni sul come si è arrivati a tutto questo e su quali passi ritengo si debbano prendere per ridurre la probabilità che si verifichi di nuovo una simile situazione (alcuni di questi passi sono già stati intrapresi, altri richiedono tempi molto più lunghi).
Giochiamo con l’input
Cominciamo col catalogare Heartbleed e col descrivere di che genere di vulnerabilità si tratta…
Per prima cosa dobbiamo studiare un po’ la feature Heartbeat del protocollo TLS e capire cosa fa e in questo ci viene in aiuto Randall di XKCD (immagine omessa per questioni di Copyright): in breve l’Heartbeat è un meccanismo per chiedere ad un server TLS se è ancora vivo in una maniera simile al caro buon vecchio ICMP Echo Request/Echo Response. Il problema è che, nell’implementazione di OpenSSL è possibile forgiare un pacchetto che abbia un messaggio breve ma che richieda una risposta lunga e la libreria, invece di ignorare tale richiesta malformata, provvederà ad allocare abbastanza spazio nella memoria per mandare indietro la risposta.
“E questo è un problema?” E’ un problema nel momento in cui in quella porzione di memoria ci sono informazioni sensibili che non verranno sovrascritte ma inviate a chi ha fatto la richiesta.
“Di che informazioni stiamo parlando?” In generale di qualsiasi informazione che sia presente nello spazio di memoria a disposizione di OpenSSL, il che può voler dire cose come:
- Traffico già criptato & spazzatura.
- Traffico non ancora criptato (token di autenticazione, email, comunicazioni VoIP).
Andiamo più in profondità
Ok, è venuto il momento tanto atteso: adesso faremo un salto dentro al codice sorgente e vedremo un po' più in dettaglio cosa ha causato tutto questo pasticcio. Come riferimento userò la patch rilasciata dai maintainer del progetto OpenBSD e la ragione è duplice:
- E’ molto leggibile e ben documentata.
- Va dritta al punto.
E adesso, finalmente, vediamo il codice C:
/* Read type and payload length first */
hbtype = *p++;
n2s(p, payload);
pl = p;
Ok, questa è una porzione di libreria che è stata tolta, il commento ci dà un indizio: “Read type and payload length first”.
Non abbiamo tutto il codice sorgente sotto gli occhi, ma è ragionevole supporre che p sia un puntatore ai dati del pacchetto TLS Heartbeat appena ricevuto e siccome il tipo è indicato nel RFC come intero a 8 bit (ma può assumere come valori solo 1 o 2) il nostro programmatore ha deciso di fare in fretta e fare due cose con un'unica istruzione: leggere il valore (salvandolo in hbtype) e portarsi al campo successivo con l'uso dell'operatore di post-incremento (il “++” dopo “p”) il “*” davanti a “p” è necessario perché altrimenti invece del valore leggeremmo l'indirizzo di memoria in cui questo si trova (e non ce ne faremmo nulla). Fin qui nulla di strano, si tratta di una pratica standard nella programmazione C anche se è malvista perché riduce la leggibilità del codice.
La linea di codice successiva è una chiamata alla funzione n2s: anche qui non abbiamo tutto il codice, ma possiamo ricavare dal contesto e dai parametri che gli vengono passati che quella funzione non faccia altro che leggere la lunghezza del messaggio di Heartbeat dal pacchetto e salvare tale lunghezza in payload. Notate bene: questa è la lunghezza dichiarata, non necessariamente la lunghezza reale del messaggio. Tenete bene a mente che non abbiamo alcuna garanzia che quello che ci viene detto corrisponda a verità e che il diavolo sta nei dettagli.
L'ultima riga serve a salvare un puntatore al messaggio vero e proprio in “pl”.
Segue una porzione che è rimasta invariata e che si occupa di controllare se è stata registrata una callback e di chiamare tale callback: le ragioni per cui si vuole poter chiamare una funzione esterna quando si comincia a processare un pacchetto possono essere le più varie, ma di solito lo si fa per avere un log per questioni di debug.
Dopo una sezione di codice aggiunto (che ignoreremo) abbiamo le righe seguenti:
if (hbtype == TLS1_HB_REQUEST)
{
unsigned char *buffer, *bp;
int r;
/* Allocate memory for the response, size is 1 bytes
* message type, plus 2 bytes payload length, plus
* payload, plus padding
*/
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
bp = buffer;
/* Enter response type, length and copy payload */
/*...Omississ...*/
/* Random padding */
RAND_pseudo_bytes(bp, padding);
r = dtls1_write_bytes(s, TLS1_RT_HEARTBEAT, buffer, 3 + payload +
padding);
if (r >= 0 && s->msg_callback)
s->msg_callback(1, s->version, TLS1_RT_HEARTBEAT,
buffer, 3 + payload + padding,
s, s->msg_callback_arg);
OPENSSL_free(buffer);
Allora, vediamo un po' cosa abbiamo qui… Questa riga qui è la radice del Male:
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
OpenSSL è una libreria multipiattaforma, il che significa che deve girare su una gran varietà di Sistemi Operativi diversi. Alcuni di questi offrono meccanismi di protezione della memoria, altri no. Per avere una base comune gli sviluppatori di OpenSSL hanno creato una loro implementazione delle chiamate malloc e free: la prima riserva della memoria mentre la seconda la libera. Il problema di questo approccio è che, se non fai le cose per bene, puoi bypassare completamente i meccanismi che il Sistema Operativo adotta per proteggere la memoria e ridurre l’impatto che possono avere certi errori di programmazione.
La chiamata malloc fa parte della libreria standard del C e si appoggia a chiamate simili del sistema operativo per allocare (riservare) una porzione di memoria che un programma in esecuzione può utilizzare come meglio crede (anche condividendola con librerie e/o altri programmi in esecuzione). malloc può riservare aree di memoria precedentemente non utilizzate da altri programmi (bene) oppure aree di memoria già utilizzate da altri processi e da questi rese libere per il riutilizzo (male perché potrebbero ancora contenere dati) mentre OPENSSL_malloc riutilizza memoria pre-allocata dalla libreria stessa (molto male) e mantiene una sua lista delle allocazioni per poter far funzionare OPENSSL_free (la funzione che si occupa di liberare la memoria per il riutilizzo). Facendo così OpenSSL bypassa i meccanismi di ASLR (Address Space Layout Randomization) messi in atto dal kernel del Sistema Operativo per ridurre l'impatto di certi errori di programmazione.
Una discussione completa sui meccanismi di protezione della memoria esula dallo scopo di questo articolo, ma invito il lettore a dare un'occhiata alle slide che Theo DeRaadt ha proposto al ruBSD 2013 e, per i più curiosi, all'articolo in merito ad ASLR su Wikipedia.
Quello che succede in quella porzione di codice è che il programmatore si è fidato della lunghezza dichiarata dal pacchetto e ha riservato una porzione di memoria pari a quella lunghezza. Come già detto OpenSSL gestisce per conto suo la memoria e, siccome la memoria non è infinita, riutilizza la memoria. Nella porzione di codice precedente quella memoria non viene “pulita” prima di essere utilizzata e quindi potrebbe contenere qualsiasi cosa. Inoltre non vengono fatti dei controlli che il messaggio sia lungo quanto dichiarato.
Se il messaggio è più breve del valore dichiarato quello che succede è che viene occupata solo parte della memoria allocata e il resto viene spedito così com'è al richiedente.
C'è una piccola consolazione: il campo lunghezza consente di avere un payload che può essere lungo al massimo 65536 byte e occorre indicare almeno un byte per il messaggio portando la quantità di dati leggibili a dall'attaccante a 65535 byte (64 kilobyte). La probabilità di trovare dati utili in una finestra così stretta si abbassa molto ed occorre anche essere in grado di distinguere i dati utili dalla spazzatura (e gli algoritmi di generazione delle chiavi crittografiche fanno di tutto per far apparire le chiavi stesse come dati casuali apparentemente senza capo nè coda), ma è già stato dimostrato che avendo abbastanza pazienza (si parla di milioni di tentativi) si può leggere anche la chiave privata usata da un server web per decrittare TUTTE le comunicazioni criptate.
Conclusioni
Il bug in questione ha tutta l'aria di essere finito lì a causa di una svista: la feature era nuovissima (ancora in fase di standardizzazione) e in seguito è stata poco utilizzata (pochi hanno sentito il bisogno di usare il TLS Hearthbeat quando ci sono decine di altre tecniche di High Availability disponibili) per cui pochi occhi si sono concentrati su quel codice.
Sicuramente è significativo che anche nel mondo dell'Open Source ci siano casi di feature “aggiunte e dimenticate” che ricevono poca o nessuna manutenzione. Ed è significativo che il presupposto principale dello sviluppo a sorgente aperto (molti occhi che guardano il codice si accorgono prima di certi errori) sia venuto meno nel caso di una delle librerie più utilizzate per la comunicazione sicura di pagine web, posta elettronica e una moltitudine di altri servizi.
Ci si è fidati della buona volontà e delle capacità di chi ha scritto OpenSSL (persone che meritano la stima e il rispetto di tutti quanti noi per il lavoro svolto) senza ricontrollare e così un errore fatto in buona fede è finito per avere un impatto clamoroso su tutta l'infrastruttura su cui si basa il web 2.0. Non basta che il codice sia visibile a tutti: occorre che qualcun altro oltre agli sviluppatori ci dia un'occhiata ogni tanto.
Ricette magiche non ce ne sono, ma questo pasticcio ha senz'altro portato all'attenzione di tutti le falle presenti in OpenSSL e la necessità di rimettere a posto quel codice nel suo complesso (e non solo la parte relativa al bug Heartbleed).
Moltissime aziende utilizzano OpenSSL nei loro prodotti (grazie anche alla licenza molto liberale) e alcuni dei player più grossi si sono resi conto che forse è il caso di dare qualcosa indietro a quei quattro gatti che lavorano su quel codice così importante. La mia speranza è che (oltre a beccarsi enormi quantità di trolling) lo sforzo degli sviluppatori venga premiato e che altra gente cominci a pensare che non basta sviluppare un daemon DHCP nell'init system ma che c'è anche bisogno di mantenere e controllare quello che già c'è.
