Undici byte e un thread in attesa

Qualcuno del Red Team di Okta ha inviato a un server 11 byte e l'ha visto mettere da parte 131 kilobyte. Il trucco sta nel modo in cui si apre una conversazione TLS. I primi quattro byte di un messaggio di handshake dichiarano quanto sarà lungo il messaggio, e le versioni più vecchie di OpenSSL credevano a quella dichiarazione, riservando il buffer prima che arrivasse il resto o che venisse eseguita una qualsiasi convalida. Il resto del messaggio non è mai arrivato. La memoria è rimasta riservata e un thread di lavoro è rimasto ad attendere dati che non sarebbero mai giunti.

Ripetuto, l'effetto non è affatto sottile. Su un server da un gigabyte la squadra ha lasciato 547 megabyte congelati in frammenti inutilizzabili. Su una macchina da sedici gigabyte ha bloccato un quarto della memoria complessiva. Sui sistemi che usano l'allocatore glibc la memoria non torna disponibile in modo pulito neppure dopo la disconnessione dell'attaccante, perché i frammenti liberati non possono essere riutilizzati. Non servivano credenziali, nessuna sessione è stata stabilita e nulla nello scambio somigliava a un attacco.

La parte che dovrebbe preoccupare un dirigente più di un tecnico

OpenSSL l'ha corretto. Le versioni 4.0.1, 3.6.3, 3.5.7, 3.4.6 e 3.0.21 sono uscite tutte il 9 giugno 2026 con il comportamento corretto, allocando memoria solo man mano che i dati arrivano davvero. Tre richieste di modifica, numerate 30792, 30793 e 30794, hanno portato il cambiamento. Poi per oltre cinque settimane non se n'è parlato. La divulgazione pubblica è giunta alla lista oss-security il 18 luglio, 39 giorni dopo che la correzione circolava già.

Il gruppo di sicurezza ha compiuto una scelta consapevole. OpenSSL adotta un sistema di gravità a quattro livelli, da Critico a Basso, e ha ritenuto che questo caso non rientrasse in nessuno di essi. La richiesta di modifica afferma con chiarezza che il gruppo ha preferito trattare la segnalazione come una correzione di "bug o irrobustimento". Non esiste quindi un identificativo CVE, né un avviso di sicurezza, né una voce nei registri delle modifiche delle versioni interessate. Ognuna di quelle assenze è una decisione, e ognuna ha eliminato un segnale che il processo di qualcuno era costruito per intercettare.

Il processo disciplinato ha perso contro quello indisciplinato

Immaginate due aziende. La prima aggiorna OpenSSL con cadenza mensile fissa, a prescindere da che cosa contenga la versione. È l'approccio da cui una funzione di sicurezza matura tende ad allontanarsi, perché consuma finestre di manutenzione su rilasci ininfluenti. Quell'azienda è protetta da giugno e non ha idea di essere mai stata a rischio.

La seconda ordina le priorità per gravità. Legge gli avvisi, valuta i CVE, anticipa Critico e Alto e rinvia il resto con una motivazione documentata. È l'approccio che supera un audit, soddisfa un assicuratore e regge una domanda del consiglio. Quell'azienda ha guardato il rilascio OpenSSL di giugno, non ha trovato contenuti di sicurezza e ha deciso, del tutto correttamente, di non spendervi una finestra di manutenzione. È ancora esposta, e il suo processo ha funzionato esattamente come progettato.

La conclusione scomoda è che aggiornare in base alla gravità significa affidare le proprie decisioni di rischio a chi quella gravità la assegna. Non è un rimprovero a OpenSSL, progetto retto in larga parte da volontari che compie scelte difendibili su una scala a quattro livelli che non deve a nessuno. È un'osservazione su dove risieda davvero il giudizio. Se il vostro processo fa salire di livello soltanto ciò che arriva già etichettato come pericoloso, allora il vostro modello di minaccia è in realtà la politica di etichettatura dei vostri fornitori.

Due cose restano vere oggi

Il percorso DTLS è stato lasciato stare. Correggerlo per bene è parso troppo invasivo per ora, perciò quel codice continua a dimensionare il buffer sulla lunghezza dichiarata dall'interlocutore. Se terminate DTLS da qualche parte, e lo fanno molti concentratori VPN, server multimediali WebRTC e gateway IoT industriali, quell'esposizione non è risolta da nulla di quanto descritto qui. Non è nemmeno un segreto nascosto. È dichiarato apertamente nella divulgazione, il che è già di per sé un avvertimento.

La seconda cosa riguarda i tempi. Di norma divulgazione e correzione arrivano insieme e difensori e attaccanti partono dalla stessa linea. Qui il codice corretto è rimasto in commit pubblici per 39 giorni prima che qualcuno spiegasse che cosa correggeva. Leggere un confronto tra commit non è un'abilità esotica. Per oltre un mese chi legge il codice ha avuto un vantaggio su chi legge i bollettini, e il secondo gruppo non sapeva che una corsa fosse cominciata.

La domanda da aggiungere alla prossima revisione

Non rifate il vostro programma sulle vulnerabilità per un errore di esaurimento memoria. Aggiungete però una domanda ricorrente alla riunione che già tenete: che cosa abbiamo rinunciato ad aggiornare questo trimestre perché è arrivato senza un livello di gravità? Non ciò che abbiamo rinviato come Basso. Ciò che non è mai entrato in coda perché nulla lo aveva etichettato. Quell'elenco esiste in ogni organizzazione e quasi nessuno lo guarda.

Poi confrontate le vostre versioni di OpenSSL con i rilasci del 9 giugno, cosa di pochi minuti, e annotate se siete coperti per politica o per fortuna. La differenza fra queste due risposte è tutto il punto. Un controllo che vi protegge per caso non è un controllo, e la prossima volta che il caso non si presenterà lo scoprirete per la via costosa.

Da leggere ora: La correzione era pubblica 81 giorni prima dell'avviso  |  Una richiesta poteva dirottare il tuo sito WordPress