Heartbleed è il nome di una vulnerabilità molto seria scoperta sulla libreria OpenSSL dalla versione 1.0.1 alla 1.0.1f incluse.
OpenSSL è utilizzata per il traffico https da molti software, tra cui Apache e nginx che da soli costituiscono il 66% dei server web, anche se bisogna rilevare che non tutti i server web hanno https abilitato.
Microsoft Internet Information Server non è interessato da questo problema.
I prodotti Apple non sono interessati dal problema, con l’eccezione dell’AirPort per cui è disponibile un aggiornamento.
Tutto è cominciato nel 2012 con la release di OpenSSL 1.0.1 che introduce il supporto di RFC6520 e implementa l’heartbeat sulle connessioni TLS. Questa funzione serve a mantenere il canale aperto e impedire, quindi, che client e server debbano rinegoziare la connessione in caso di temporanea inattività. L’espediente dell’heartbeat o keep-alive è utilizzato in molti contesti in cui si invia un pacchetto dati senza informazioni con il solo scopo di resettare eventuali contatori di inattività.
Il problema di OpenSSL è che una riposta al’heartbeat modificata ad arte può rivelare all’attaccante informazioni di vario tipo. Non è possibile utilizzare questa vulnerabilità per eseguire codice sul server remoto, ma questo non è certo un fattore mitigante, vediamo perché.
RFC6520 prescrive che il pacchetto di heartbeat sia al massimo di 16k (214 byte), ma OpenSSL genera pacchetti molto più piccoli.
Il protocollo prevede che il client invii un pacchetto di heartbeat e il server risponda copiando quello che ha ricevuto dal client nella risposta in modo tale che il client riconosca come legittima la risposta. Il pacchetto di heartbeat di OpenSSL ha questo formato:
- 0x01 costante che denota
TLS1_HB_REQUEST - due byte con la dimensione del pacchetto codificata a 16 bit
- due byte codificati a 16 bit con il numero di sequenza del pacchetto
- 16 byte di dati casuali
- altri 16 byte di dati casuali richiesti dallo standard RFC6250
Nella risposta il server copia i dati ricevuti e li rispedisce al client usando questo codice:
/* Allocate memory for the response, size is 1 byte * 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 */*bp++ = TLS1_HB_RESPONSE;s2n(payload, bp);memcpy(bp, pl, payload);Nel codice sopra payload è la dimensione del pacchetto dichiarata dal mittente (non calcolata dal server). Se il mittente anziché dichiarare la vera dimensione del pacchetto mettesse 0xffff (il numero massimo esprimibile con due byte senza segno) il destinatario copierebbe i 34 byte del pacchetto vero e gli altri 65501 byte che si trovano in memoria dopo il pacchetto legittimo e li invierebbe al mittente.
Non è possibile stabilire in maniera deterministica cosa contengono quei 65501 byte, verosimilmente sono dati utilizzati da OpenSSL. Alcuni test hanno rivelato che in risposta OpenSSL può fornire molti dati sensibili, tra cui anche la chiave privata che il server utilizza per cifrare le comunicazioni.
Molti siti commerciali presentano questo baco pericoloso e i tecnici sono (si spera) al lavoro per aggiornare le librerie OpenSSL.
Il baco è stato scoperto da Neel Mehta di Google Security, molti enti hanno emesso delle note in merito (CERT FI e US-CERT) ed è anche disponibile un sito dedicato.
Aggiornamento: Con questo script Python è possibile verificare se un sito è vulnerabile. Consiglio caldamente di usare script sui propri computer anziché servizi online per evitare di rivelare a terzi l’esistenza di siti vulnerabili.
L’autore della modifica rovinosa è Robin Seggelmann e questo è il checkin del codice bacato.
Elric: As I look at you, Ambassador Mollari, I see a great hand reaching out of the stars. The hand is your hand. And I hear sounds – the sounds of billions of people calling your name.
Londo: My followers?
Elric: Your victims.
Articolo modificato dopo la pubblicazione iniziale:
- 24/4/2014 aggiunto riferimento ad Apple AirPort [via Paolo Attivissimo]
Lascia un commento