S'ha identificat una vulnerabilitat crítica (CVE-2021-43527) al conjunt de biblioteques criptogràfiques NSS (Network Security Services) desenvolupat per Mozilla, que pot provocar l'execució de codi atacant quan es processen signatures digitals DSA o RSA-PSS especificades mitjançant el Mètode de codificació DER (Distinguished Encoding Rules). El problema, amb el nom en clau BigSig, es resol a NSS 3.73 i NSS ESR 3.68.1. Les actualitzacions de paquets a les distribucions estan disponibles per a Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Encara no hi ha actualitzacions disponibles per a Fedora.
El problema es produeix a les aplicacions que utilitzen NSS per gestionar signatures digitals CMS, S/MIME, PKCS #7 i PKCS #12, o quan es verifiquen certificats en implementacions TLS, X.509, OCSP i CRL. La vulnerabilitat pot aparèixer en diverses aplicacions de client i servidor que admeten TLS, DTLS i S/MIME, clients de correu electrònic i visualitzadors de PDF que utilitzen la trucada NSS CERT_VerifyCertificate() per verificar signatures digitals.
LibreOffice, Evolution i Evince s'esmenten com a exemples d'aplicacions vulnerables. Potencialment, el problema també pot afectar projectes com Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss per al servidor Apache http, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Tanmateix, la vulnerabilitat no apareix a Firefox, Thunderbird i Tor Browser, que utilitzen una biblioteca mozilla::pkix independent, també inclosa a NSS, per a la verificació. Els navegadors basats en Chromium (tret que estiguin dissenyats específicament amb NSS), que utilitzaven NSS fins al 2015, però després van canviar a BoringSSL, tampoc es veuen afectats pel problema.
La vulnerabilitat és causada per un error al codi de verificació del certificat a la funció vfy_CreateContext del fitxer secvfy.c. L'error es produeix tant quan el client llegeix un certificat del servidor com quan el servidor els processa. Quan es verifica una signatura digital codificada per DER, NSS descodifica la signatura en un buffer de mida fixa i passa el buffer al mòdul PKCS #11. Durant el processament posterior, la mida es comprova incorrectament per a les signatures DSA i RSA-PSS, la qual cosa comporta un desbordament de la memòria intermèdia assignada per a l'estructura VFYContextStr si la mida de la signatura digital supera els 16384 bits (s'assignen 2048 bytes per a la memòria intermèdia, però no es comprova que la signatura pugui ser més gran) ).
El codi que conté la vulnerabilitat es remunta al 2003, però no va suposar una amenaça fins a una refactorització realitzada el 2012. El 2017, es va cometre el mateix error en implementar el suport RSA-PSS. Per dur a terme un atac, no és necessària la generació intensiva de recursos de determinades claus per obtenir les dades necessàries, ja que el desbordament es produeix en l'etapa anterior a la comprovació de la correcció de la signatura digital. La part de les dades que va més enllà dels límits s'escriu en una àrea de memòria que conté punters a funcions, la qual cosa simplifica la creació d'explotacions de treball.
La vulnerabilitat va ser descoberta pels investigadors de Google Project Zero mentre experimentaven amb nous mètodes de prova de fuzzing i és una bona demostració de com les vulnerabilitats trivials poden passar desapercebudes durant molt de temps en un projecte conegut àmpliament provat:
- El codi NSS el manté un equip de seguretat experimentat que utilitza tècniques d'anàlisi d'errors i proves d'última generació. Hi ha diversos programes en marxa per pagar recompenses importants per identificar vulnerabilitats a NSS.
- NSS va ser un dels primers projectes a unir-se a la iniciativa oss-fuzz de Google i també es va provar al sistema de proves de fuzz basat en libFuzzer de Mozilla.
- El codi de la biblioteca s'ha comprovat moltes vegades en diversos analitzadors estàtics, inclòs el control del servei Coverity des del 2008.
- Fins al 2015, NSS s'utilitzava a Google Chrome i l'equip de Google va verificar de manera independent independentment de Mozilla (des del 2015, Chrome va canviar a BoringSSL, però es manté el suport per al port basat en NSS).
Els principals problemes pels quals el problema va romandre sense detectar durant molt de temps:
- La biblioteca modular NSS i les proves de fuzzing no es van dur a terme en conjunt, sinó a nivell de components individuals. Per exemple, el codi per descodificar DER i processar els certificats es va comprovar per separat; durant el fuzzing, es podria haver obtingut un certificat que comportaria la manifestació de la vulnerabilitat en qüestió, però la seva comprovació no va arribar al codi de verificació i el problema no va arribar. revelar-se.
- Durant les proves de fuzzing, es van establir restriccions estrictes a la mida de sortida (10000 bytes) en absència de restriccions similars a NSS (moltes estructures en mode normal podrien tenir una mida de més de 10000 bytes, de manera que es necessitaven més dades d'entrada per identificar problemes). . Per a una verificació completa, el límit hauria d'haver estat de 224-1 bytes (16 MB), que correspon a la mida màxima del certificat permesa a TLS.
- Concepció errònia sobre la cobertura del codi de prova de fuzz. El codi vulnerable es va provar activament, però utilitzant fuzzers que no van poder generar les dades d'entrada necessàries. Per exemple, fuzzer tls_server_target va utilitzar un conjunt predefinit de certificats ja fets, que limitava la comprovació del codi de verificació del certificat només als missatges TLS i als canvis d'estat del protocol.
Font: opennet.ru