Nell'insieme delle librerie crittografiche NSS (Network Security Services), sviluppato da Mozilla, è stata identificata una vulnerabilità critica (CVE-2021-43527) che potrebbe portare all'esecuzione di codice malevolo durante l'elaborazione di firme digitali DSA o RSA-PSS, specificate utilizzando il metodo di codifica DER (Distinguished Encoding Rules). Il problema, soprannominato BigSig, è stato risolto 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.
Il problema si manifesta nelle applicazioni che utilizzano NSS per elaborare 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à potrebbe emergere in varie applicazioni client e server che supportano TLS, DTLS e S/MIME, nei client di posta e nei lettori PDF che utilizzano la chiamata NSS CERT_VerifyCertificate() per verificare le firme digitali.
Esempi di applicazioni vulnerabili includono LibreOffice, Evolution ed Evince. Potenzialmente, il problema potrebbe riguardare anche progetti come Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss per il server web Apache, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Tuttavia, la vulnerabilità non si manifesta in Firefox, Thunderbird e Tor Browser, che utilizzano una libreria separata mozilla::pkix, anch'essa inclusa in NSS. I browser basati su Chromium (se non costruiti specificamente con NSS) non sono vulnerabili, poiché hanno utilizzato NSS fino al 2015, prima di passare 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 dei certificati dei client. Durante la verifica della firma digitale codificata con il metodo DER, NSS decodifica la firma in un buffer di dimensioni fisse e passa questo buffer al modulo PKCS #11. Nella fase successiva di elaborazione, per le firme DSA e RSA-PSS, la dimensione non viene controllata correttamente, il che porta a un overflow del buffer allocato per la struttura VFYContextStr, se la dimensione della firma digitale supera i 16384 bit (a tale buffer sono allocati 2048 byte, ma non viene controllato che la firma possa essere di dimensioni maggiori).
Il codice contenente la vulnerabilità è tracciato dal 2003, ma non ha rappresentato una minaccia fino al rifacimento effettuato nel 2012. Nel 2017, durante l'implementazione del supporto RSA-PSS, si è verificato lo stesso errore. Per effettuare un attacco non è necessaria la generazione dispendiosa di determinati chiavi per ottenere i dati desiderati, poiché il buffer overflow avviene nella fase precedente alla verifica della correttezza della firma digitale. Una parte dei dati che esce dai limiti viene scritta in un'area di memoria contenente puntatori a funzioni, il che semplifica la creazione di exploit funzionanti.
La vulnerabilità è stata individuata dai ricercatori di Google Project Zero durante esperimenti con nuovi metodi di fuzzing e rappresenta una buona dimostrazione di come in un progetto noto e ampiamente testato possano rimanere inosservate per lungo tempo vulnerabilità banali:
- Il codice NSS è supportato da un team esperto responsabile della sicurezza, che applica metodi moderni di test e analisi degli errori. Sono attive diverse programmi per la concessione di ricompense significative per la scoperta di vulnerabilità in NSS.
- NSS è stato uno dei primi progetti a unirsi all'iniziativa Google oss-fuzz e è stato anche testato nel sistema di fuzzing in sviluppo da Mozilla basato su libFuzzer.
- Il codice della libreria è stato ripetutamente verificato in vari analizzatori statici, incluso il servizio Coverity dal 2008.
- Fino al 2015, NSS è stato utilizzato in Google Chrome e, indipendentemente da Mozilla, è stato testato dal team di Google (dal 2015 Chrome è passato a BoringSSL, ma il supporto per il porting basato su NSS è mantenuto).
Le principali problematiche per cui il problema è rimasto inosservato per lungo tempo:
- NSS è una libreria modulare e il fuzzing è stato effettuato non a livello complessivo, ma a livello di singoli componenti. Ad esempio, il codice di decodifica DER e la gestione dei certificati sono stati esaminati separatamente: durante il fuzzing è stato possibile ottenere un certificato che provocava la vulnerabilità in discussione, ma la sua verifica non raggiungeva il codice di validazione e il problema non veniva rilevato.
- Durante i test di fuzzing, sono stati imposti severi limiti sulla dimensione dell'output (10.000 byte), mentre non ci sono stati limiti similari in NSS (molte strutture in modalità standard possono avere dimensioni superiori a 10.000 byte, quindi erano necessari volumi maggiori di dati di input per identificare i problemi). Per una verifica completa, il limite doveva essere 224-1 byte (16 MB), corrispondente alla dimensione massima del certificato consentito in TLS.
- Falsi concetti sulla copertura del codice dai test di fuzzing. Il codice vulnerabile è stato attivamente testato, ma utilizzando fuzzer che non erano in grado di generare i dati di input necessari. Ad esempio, il fuzzer tls_server_target ha utilizzato un insieme predeterminato di certificati pronti, limitando il test del codice di verifica del certificato solo ai messaggi TLS e ai cambiamenti di stato del protocollo.
Fonte: opennet.ru
