Nel pacchetto di librerie crittografiche NSS (Network Security Services), sviluppato da Mozilla, è stata identificata una vulnerabilità critica (CVE-2021-43527) che può portare all'esecuzione di codice da parte di un aggressore durante l'elaborazione di firme digitali DSA o RSA-PSS, create utilizzando il metodo di codifica DER (Distinguished Encoding Rules). La problematica, nota con il nome in codice BigSig, è stata risolta nelle versioni NSS 3.73 e NSS ESR 3.68.1. Gli aggiornamenti dei pacchetti sono disponibili per le distribuzioni Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Gli aggiornamenti per Fedora non sono ancora disponibili.
La problematica si manifesta nelle applicazioni che utilizzano NSS per l'elaborazione di 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ò emergere in varie applicazioni client e server che supportano TLS, DTLS e S/MIME, così come nei client di posta e nei lettori PDF che utilizzano la chiamata NSS CERT_VerifyCertificate() per verificare le firme digitali.
A titolo di esempio, le applicazioni vulnerabili includono LibreOffice, Evolution e Evince. Potenzialmente la problematica potrebbe 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 e Oracle Directory Server Enterprise Edition. Tuttavia, la vulnerabilità non si manifesta in Firefox, Thunderbird e Tor Browser, dove viene utilizzata una libreria separata mozilla::pkix per la verifica, anch'essa parte di NSS. Anche i browser basati su Chromium non sono vulnerabili (se non sono stati specificamente compilati con NSS) e quelli che hanno utilizzato NSS fino al 2015, sono stati poi migrati a BoringSSL.
La vulnerabilità è causata da un errore nel codice di verifica dei certificati nella funzione vfy_CreateContext del file secvfy.c. L'errore si manifesta sia durante la lettura del certificato da parte del client dal server, sia durante l'elaborazione. server certificati dei clienti. Durante il processo di verifica della firma digitale codificata con il metodo DER, NSS decodifica la firma in un buffer di dimensione fissa e la trasmette al modulo PKCS #11. Nella fase di elaborazione successiva, per le firme DSA e RSA-PSS non viene verificata correttamente la dimensione, portando a un overflow del buffer allocato per la struttura VFYContextStr, se la dimensione della firma digitale supera i 16384 bit (il buffer è allocato a 2048 byte, ma non viene controllato che la firma possa essere di dimensioni superiori).
Il codice contenente la vulnerabilità è tracciato dal 2003, ma non presentava minacce fino al refactoring avvenuto nel 2012. Nel 2017, durante l'implementazione del supporto RSA-PSS, è stato commesso lo stesso errore. Per eseguire l'attacco non è necessaria una generazione dispendiosa di determinati tasti per ottenere i dati necessari, poiché l'overflow si verifica in fase antecedente alla verifica della correttezza della firma digitale. La parte dei dati che esce dai limiti viene scritta nello spazio di memoria contenente puntatori a funzioni, facilitando la creazione di exploit funzionanti.
La vulnerabilità è stata scoperta dai ricercatori di Google Project Zero durante esperimenti con nuovi metodi di fuzzing e rappresenta una buona dimostrazione di come vulnerabilità triviali possano rimanere inosservate per lungo tempo anche in un progetto ampiamente testato e ben noto.
- Il codice NSS è accompagnato da un team esperto responsabile della sicurezza, che utilizza metodi moderni di test e analisi degli errori. Sono attive diverse programmazione per il pagamento di premi significativi per la scoperta di vulnerabilità in NSS.
- NSS è stato uno dei primi progetti a unirsi all'iniziativa Google oss-fuzz ed è stato anche testato all'interno del sistema di fuzzing in sviluppo di Mozilla basato su libFuzzer.
- Il codice della libreria è stato verificato più volte con diversi analizzatori statici, incluso il servizio Coverity che monitora dal 2008.
- Fino al 2015, NSS è stato utilizzato in Google Chrome e controllato indipendentemente da Mozilla dal team di Google (a partire dal 2015 Chrome è passato a BoringSSL, ma il supporto per il porting basato su NSS rimane).
I principali problemi che hanno fatto sì che la vulnerabilità rimanesse inosservata per lungo tempo:
- La libreria modulare NSS e il testing fuzzing sono stati condotti non a livello globale, ma a livello di singoli componenti. Ad esempio, il codice di decodifica DER e il trattamento dei certificati sono stati testati separatamente: durante il fuzzing è stato possibile generare un certificato che potesse manifestare la vulnerabilità in questione, ma la sua verifica non raggiungeva il codice di validazione e il problema non si manifestava.
- Durante il testing fuzzing, sono stati imposti rigidi limiti alla dimensione dell'output (10.000 byte) mentre non esistevano restrizioni simili in NSS (molte strutture in modalità normale potevano avere dimensioni superiori a 10.000 byte, per cui era necessario un maggior volume di dati in ingresso per identificare problemi). Per un'adeguata verifica, il limite avrebbe dovuto essere di 224-1 byte (16 MB), corrispondente alla dimensione massima del certificato consentita in TLS.
- Una comprensione errata della copertura del codice nei test di fuzzing. Il codice vulnerabile è stato attivamente testato, ma utilizzando fuzzer incapaci di generare i necessari input. Ad esempio, il fuzzer tls_server_target ha utilizzato un insieme predefinito di certificati pronti, limitando così il controllo del codice di verifica del certificato solo ai messaggi TLS e alle variazioni dello stato del protocollo.
Fonte: opennet.ru
