È stata identificata una vulnerabilità critica (CVE-2021-43527) nell'insieme delle librerie crittografiche NSS (Network Security Services) sviluppate da Mozilla, che può portare all'esecuzione di codice malintenzionato durante l'elaborazione delle firme digitali DSA o RSA-PSS specificate utilizzando il metodo Metodo di codifica DER (Distinguished Encoding Rules). Il problema, nome in codice BigSig, è stato risolto in NSS 3.73 e NSS ESR 3.68.1. Gli aggiornamenti dei pacchetti nelle distribuzioni sono disponibili per Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Non ci sono ancora aggiornamenti disponibili per Fedora.
Il problema si verifica nelle applicazioni che utilizzano NSS per gestire le firme digitali CMS, S/MIME, PKCS #7 e PKCS #12 o durante la verifica dei certificati nelle implementazioni TLS, X.509, OCSP e CRL. La vulnerabilità può comparire in varie applicazioni client e server che supportano TLS, DTLS e S/MIME, client di posta elettronica e visualizzatori PDF che utilizzano la chiamata NSS CERT_VerifyCertificate() per verificare le firme digitali.
LibreOffice, Evolution ed Evince sono menzionati come esempi di applicazioni vulnerabili. Potenzialmente il problema può riguardare anche progetti come Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss per il server http Apache, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Tuttavia, la vulnerabilità non appare in Firefox, Thunderbird e Tor Browser, che utilizzano una libreria mozilla::pkix separata, inclusa anche in NSS, per la verifica. Anche i browser basati su Chromium (a meno che non siano appositamente realizzati con NSS), che utilizzavano NSS fino al 2015, ma poi sono passati a BoringSSL, non sono interessati dal problema.
La vulnerabilità è causata da un errore nel codice di verifica del certificato nella funzione vfy_CreateContext dal file secvfy.c. L'errore si verifica sia quando il client legge un certificato dal server sia quando il server elabora i certificati client. Quando si verifica una firma digitale con codifica DER, NSS decodifica la firma in un buffer di dimensione fissa e passa il buffer al modulo PKCS #11. Durante l'ulteriore elaborazione, la dimensione viene controllata in modo errato per le firme DSA e RSA-PSS, il che porta ad un overflow del buffer allocato per la struttura VFYContextStr se la dimensione della firma digitale supera 16384 bit (per il buffer vengono allocati 2048 byte, ma non viene controllato che la firma possa essere più grande) ).
Il codice contenente la vulnerabilità risale al 2003, ma non rappresentava una minaccia fino al refactoring effettuato nel 2012. Nel 2017 è stato commesso lo stesso errore durante l’implementazione del supporto RSA-PSS. Per effettuare un attacco non è necessaria la generazione ad alta intensità di risorse di determinate chiavi per ottenere i dati necessari, poiché l'overflow avviene nella fase precedente alla verifica della correttezza della firma digitale. La parte dei dati che va oltre i confini viene scritta in un'area di memoria contenente puntatori a funzioni, il che semplifica la creazione di exploit funzionanti.
La vulnerabilità è stata scoperta dai ricercatori di Google Project Zero mentre sperimentavano nuovi metodi di test fuzzing ed è una buona dimostrazione di come vulnerabilità banali possano passare inosservate per lungo tempo in un progetto ben noto e ampiamente testato:
- Il codice NSS è gestito da un team di sicurezza esperto che utilizza tecniche di test e analisi degli errori all'avanguardia. Esistono diversi programmi in atto per pagare ricompense significative per l’identificazione delle vulnerabilità negli NSS.
- NSS è stato uno dei primi progetti ad aderire all'iniziativa oss-fuzz di Google ed è stato anche testato nel sistema di test fuzz basato su libFuzzer di Mozilla.
- Il codice della libreria è stato controllato più volte in vari analizzatori statici, incluso il monitoraggio da parte del servizio Coverity dal 2008.
- Fino al 2015 NSS veniva utilizzato in Google Chrome ed era verificato in modo indipendente dal team di Google indipendentemente da Mozilla (dal 2015 Chrome è passato a BoringSSL, ma rimane il supporto per il port basato su NSS).
I principali problemi a causa dei quali il problema è rimasto inosservato per molto tempo:
- La libreria modulare NSS e i test di fuzzing non sono stati condotti nel loro insieme, ma a livello dei singoli componenti. Ad esempio, il codice per la decodifica del DER e l'elaborazione dei certificati è stato controllato separatamente: durante il fuzzing si sarebbe potuto ottenere un certificato che avrebbe portato alla manifestazione della vulnerabilità in questione, ma il suo controllo non è arrivato al codice di verifica e il problema non si è risolto rivelarsi.
- Durante il test fuzzing, sono state impostate restrizioni rigorose sulla dimensione dell'output (10000 byte) in assenza di restrizioni simili in NSS (molte strutture in modalità normale potrebbero avere una dimensione superiore a 10000 byte, quindi erano necessari più dati di input per identificare i problemi) . Per una verifica completa, il limite avrebbe dovuto essere 224-1 byte (16 MB), che corrisponde alla dimensione massima del certificato consentita in TLS.
- Idea sbagliata sulla copertura del codice del test fuzz. Il codice vulnerabile è stato testato attivamente, ma utilizzando fuzzer che non erano in grado di generare i dati di input necessari. Ad esempio, fuzzer tls_server_target utilizzava un set predefinito di certificati già pronti, che limitava il controllo del codice di verifica del certificato solo ai messaggi TLS e alle modifiche dello stato del protocollo.
Fonte: opennet.ru