Vulnerabilità di esecuzione di codice in Mozilla NSS durante u processu di certificati

Una vulnerabilità critica (CVE-2021-43527) hè stata identificata in u settore NSS (Network Security Services) di biblioteche criptografiche sviluppate da Mozilla, chì ponu purtà à l'esekzione di codice di l'attaccante durante u processu di e firme digitali DSA o RSA-PSS specificate cù u Metudu di codificazione DER (Distinguished Encoding Rules). U prublema, nome in codice BigSig, hè risolta in NSS 3.73 è NSS ESR 3.68.1. L'aghjurnamenti di i pacchetti in distribuzioni sò dispunibuli per Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Ùn ci sò micca aghjurnamenti dispunibili per Fedora.

U prublema si trova in l'applicazioni chì utilizanu NSS per trattà a firma digitale CMS, S/MIME, PKCS #7 è PKCS #12, o quandu verificate certificati in implementazioni TLS, X.509, OCSP è CRL. A vulnerabilità pò apparisce in diverse applicazioni di cliente è servitore chì supportanu TLS, DTLS è S/MIME, clienti di email è visori PDF chì utilizanu a chjama NSS CERT_VerifyCertificate () per verificà e firme digitali.

LibreOffice, Evolution è Evince sò citati cum'è esempi di applicazioni vulnerabili. Potenzialmente, u prublema pò ancu influenzà prughjetti cum'è Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss per u servitore Apache http, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Tuttavia, a vulnerabilità ùn appare micca in Firefox, Thunderbird è Tor Browser, chì utilizanu una libreria mozilla::pkix separata, ancu inclusa in NSS, per a verificazione. I navigatori basati in Chromium (salvo chì sò specificamente custruiti cù NSS), chì anu utilizatu NSS finu à u 2015, ma dopu cambiatu à BoringSSL, ùn sò ancu micca affettati da u prublema.

A vulnerabilità hè causata da un errore in u codice di verificazione di certificatu in a funzione vfy_CreateContext da u schedariu secvfy.c. L'errore si trova sia quandu u cliente leghje un certificatu da u servitore è quandu u servitore processa i certificati di u cliente. Quandu verificate una firma digitale codificata in DER, NSS decodifica a firma in un buffer di dimensione fissa è passa u buffer à u modulu PKCS #11. Durante l'elaborazione ulteriore, a dimensione hè verificata incorrectamente per e signature DSA è RSA-PSS, chì porta à un overflow di u buffer attribuitu à a struttura VFYContextStr se a dimensione di a firma digitale supera 16384 bit (2048 byte sò attribuiti per u buffer, ma ùn hè micca verificatu chì a firma pò esse più grande) ).

U codice chì cuntene a vulnerabilità pò esse rintracciatu in u 2003, ma ùn era micca una minaccia finu à un refactoring realizatu in 2012. In 2017, u listessu sbagliu hè statu fattu quandu implementava u supportu RSA-PSS. Per fà un attaccu, a generazione intensiva di risorse di certi chjavi ùn hè micca necessariu per ottene e dati necessarii, postu chì l'overflow si trova in u stadiu prima di verificà a correttezza di a firma digitale. A parte di e dati chì supera i cunfini hè scritta à una zona di memoria chì cuntene punters à e funzioni, chì simplificà a creazione di sfruttamenti di travagliu.

A vulnerabilità hè stata scuperta da i circadori di Google Project Zero mentre sperimentavanu novi metudi di prova di fuzzing è hè una bona dimustrazione di cumu e vulnerabilità triviali ponu ùn esse rilevate per un bellu pezzu in un prughjettu assai cunnisciutu assai pruvatu:

  • U codice NSS hè mantinutu da una squadra di sicurezza esperta chì utilizeghja tecniche di teste di punta è analisi di errore. Ci sò parechji prugrammi in u locu per pagà ricumpensa significativa per identificà e vulnerabilità in NSS.
  • NSS hè statu unu di i primi prughjetti à unisce à l'iniziativa oss-fuzz di Google è hè statu ancu pruvatu in u sistema di prova fuzz basatu in Mozilla libFuzzer.
  • U codice di a biblioteca hè stata verificata parechje volte in diversi analizzatori statici, cumpresu esse monitoratu da u serviziu Coverity da 2008.
  • Finu à u 2015, NSS hè stata utilizata in Google Chrome è hè stata verificata indipindente da a squadra di Google indipindentamente da Mozilla (dapoi u 2015, Chrome hà cambiatu à BoringSSL, ma u supportu per u portu basatu in NSS resta).

I prublemi principali per via di i quali u prublema ùn hè micca rilevatu per un bellu pezzu:

  • A libreria modulare NSS è a prova di fuzzing sò stati realizati micca in tuttu, ma à u livellu di cumpunenti individuali. Per esempiu, u codice per a decodificazione di DER è i certificati di processazione hè stata verificata separatamente - durante u fuzzing, un certificatu puderia esse acquistatu chì porta à a manifestazione di a vulnerabilità in quistione, ma a so verificazione ùn hà micca righjuntu u codice di verificazione è u prublema ùn hà micca. si rivela.
  • Durante a prova di fuzzing, restrizioni strette sò state stabilite nantu à a dimensione di output (10000 byte) in l'absenza di restrizioni simili in NSS (assai strutture in modu normale puderia avè una dimensione di più di 10000 byte, cusì più dati di input era necessariu per identificà i prublemi) . Per a verificazione cumpleta, u limitu duveria esse 224-1 byte (16 MB), chì currisponde à a dimensione massima di certificatu permessa in TLS.
  • Misconception nantu à a cobertura di codice fuzz testing. U codice vulnerabile hè statu pruvatu attivamente, ma cù fuzzers chì ùn anu micca pussutu generà i dati di input necessarii. Per esempiu, fuzzer tls_server_target hà utilizatu un inseme predefinitu di certificati pronti, chì limitanu a verificazione di u codice di verificazione di u certificatu à solu i missaghji TLS è i cambiamenti di u statu di u protocolu.

Source: opennet.ru

Add a comment