Una settimana prima dal rilascio della nuova versione 3.0.7 del progetto OpenSSL (pubblicata il 1° novembre), il team aveva preavvisato dell’arrivo di una correzione ad una vulnerabilità critica. Al dunque si è scoperto che esistono correttivi “soltanto” per due vulnerabilità di gravità alta: la CVE-2022-3786 (“X.509 Email Address Variable Length Buffer Overflow”) e la CVE-2022-3602 (“X.509 Email Address 4-byte Buffer Overflow”), entrambe capaci di rendere possibile un attacco BOF (Buffer Overflow) ed il conseguente DoS (Denial of Service). Le vulnerabilità affliggono tutte le versioni di OpenSSL dalla versione 3.0 in avanti, quindi tutte le versioni in giro da almeno settembre del 2021. Allo stato non si hanno notizie di PoC o avvistamenti in natura di attacchi rispetto a queste vulnerabilità, pertanto è difficile capire le motivazioni per una comunicazione così allarmistica prima di un naturale rilascio di un insieme di correttivi ad un software. La spiegazione la fornisce direttamente il progetto OpenSSL che indica la CVE-2022-3602 responsabile della valutazione allarmistica iniziale: questa infatti è una vulnerabilità che causa un overflow arbitrario del buffer dello stack di 4 byte e inizialmente sembrava poter portare all'esecuzione di codice da remoto (RCE). La politica di OpenSSL in presenza di RCE stima la gravità della vulnerabilità a livello critico. Osservazioni sul campo da parte di ricercatori indipendenti hanno però dimostrato come, pur realizzando un buffer overflow in alcune distribuzioni Linux, in nessun caso si è pervenuti a sovrascrittura di aree già utilizzate e tali da causare un crash o una RCE. Molte piattaforme moderne hanno sistemi di protezione dello stack da impedirne lo sfruttamento in tal senso, quantomeno rispetto al RCE: al più quello che potrebbe succedere è un banale crash, non così poi dannoso da giustificare il livello critico per la vulnerabilità. Ma ovviamente, in termini conservativi, non si può affermare con certezza che questo non possa accadere in contesti particolari indotti dalla possibilità di sfruttare OpenSSL a partire dai suoi sorgenti in ambienti estranei ai test condotti. A differenza della precedente, la vulnerabilità CVE-2022-3786 non è stata mai valutata come critica in quanto l’attaccante disporrebbe solo del controllo della lunghezza e non del contenuto del buffer nella realizzazione del BOF, pertanto l’RCE è sempre stato escluso come ipotesi. In ogni caso entrambi i difetti sembrano siano stati introdotti (come riferisce OpenSSL) quanto è stata implementata la decodifica punycode (per utilizzo di alfabeti Unicode con i DNS) nell’elaborazione dei vincoli su nomi di dominio nei certificati X.509. Per sfruttare entrambi i difetti, un utente malintenzionato dovrebbe convincere un'autorità di certificazione a firmare un certificato dannoso oppure forzare una applicazione a proseguire la verifica di un certificato anche quando non sia riuscita a costruire un percorso verso un emittente di certificati attendibile. Dunque, per OpenSSL, qualsiasi applicazione che verifichi i certificati X.509 ricevuti da fonti non attendibili dovrebbe essere considerata vulnerabile. Sono inclusi i client TLS e i server TLS configurati per l'utilizzo dell'autenticazione client TLS. Non resta quindi che applicare la nuova versione per correggere i problemi e i potenziali rischi. 

Tweet