En kritisk sårbarhed (CVE-2021-43527) er blevet identificeret i NSS-sættet (Network Security Services) af kryptografiske biblioteker udviklet af Mozilla, som kan føre til eksekvering af angriberkode ved behandling af digitale DSA- eller RSA-PSS-signaturer, der er specificeret ved hjælp af DER-kodningsmetode ( Distinguished Encoding Rules). Problemet med kodenavnet BigSig er løst i NSS 3.73 og NSS ESR 3.68.1. Pakkeopdateringer i distributioner er tilgængelige til Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Der er ingen tilgængelige opdateringer til Fedora endnu.
Problemet opstår i applikationer, der bruger NSS til at håndtere CMS, S/MIME, PKCS #7 og PKCS #12 digitale signaturer, eller ved verificering af certifikater i TLS, X.509, OCSP og CRL implementeringer. Sårbarheden kan forekomme i forskellige klient- og serverapplikationer, der understøtter TLS, DTLS og S/MIME, e-mail-klienter og PDF-fremvisere, der bruger NSS CERT_VerifyCertificate()-kaldet til at verificere digitale signaturer.
LibreOffice, Evolution og Evince nævnes som eksempler på sårbare applikationer. Potentielt kan problemet også påvirke projekter som Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss til Apache http-serveren, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Sårbarheden vises dog ikke i Firefox, Thunderbird og Tor Browser, som bruger et separat mozilla::pkix-bibliotek, også inkluderet i NSS, til verifikation. Chrom-baserede browsere (medmindre de er specifikt bygget med NSS), som brugte NSS indtil 2015, men derefter skiftede til BoringSSL, er heller ikke berørt af problemet.
Sårbarheden er forårsaget af en fejl i certifikatbekræftelseskoden i funktionen vfy_CreateContext fra filen secvfy.c. Fejlen opstår både når klienten læser et certifikat fra serveren, og når serveren behandler klientcertifikater. Når du verificerer en DER-kodet digital signatur, afkoder NSS signaturen til en buffer med fast størrelse og sender bufferen til PKCS #11-modulet. Under videre behandling kontrolleres størrelsen forkert for DSA- og RSA-PSS-signaturer, hvilket fører til et overløb af bufferen allokeret til VFYContextStr-strukturen, hvis størrelsen af den digitale signatur overstiger 16384 bit (2048 bytes er allokeret til bufferen, men det er ikke kontrolleret, at signaturen kan være større) ).
Koden, der indeholder sårbarheden, kan spores tilbage til 2003, men den udgjorde ikke en trussel, før en refaktorering udført i 2012. I 2017 blev den samme fejl begået ved implementering af RSA-PSS support. For at udføre et angreb kræves der ikke ressourcekrævende generering af visse nøgler for at opnå de nødvendige data, da overløbet sker på stadiet før kontrol af rigtigheden af den digitale signatur. Den del af dataene, der går ud over grænserne, skrives til et hukommelsesområde, der indeholder pointere til funktioner, hvilket forenkler oprettelsen af arbejdsudnyttelser.
Sårbarheden blev opdaget af forskere fra Google Project Zero, mens de eksperimenterede med nye fuzzing testmetoder og er en god demonstration af, hvordan trivielle sårbarheder kan forblive uopdaget i lang tid i et bredt testet velkendt projekt:
- NSS-koden vedligeholdes af et erfarent sikkerhedsteam, der bruger state-of-the-art test- og fejlanalyseteknikker. Der er flere programmer på plads til at betale betydelige belønninger for at identificere sårbarheder i NSS.
- NSS var et af de første projekter, der sluttede sig til Googles oss-fuzz-initiativ og blev også testet i Mozillas libFuzzer-baserede fuzz-testsystem.
- Bibliotekskoden er blevet kontrolleret mange gange i forskellige statiske analysatorer, herunder blevet overvåget af Coverity-tjenesten siden 2008.
- Indtil 2015 blev NSS brugt i Google Chrome og blev uafhængigt verificeret af Google-teamet uafhængigt af Mozilla (siden 2015 skiftede Chrome til BoringSSL, men understøttelse af den NSS-baserede port forbliver).
De vigtigste problemer, som skyldes, at problemet forblev uopdaget i lang tid:
- Det modulære NSS-bibliotek og fuzzing-test blev ikke udført som en helhed, men på niveauet af individuelle komponenter. For eksempel blev koden til afkodning af DER og behandling af certifikater kontrolleret separat - under fuzzing kunne der være opnået et certifikat, der ville føre til manifestationen af den pågældende sårbarhed, men dens kontrol nåede ikke frem til verifikationskoden, og problemet nåede ikke åbenbare sig.
- Under fuzzing-testning blev der sat strenge restriktioner på outputstørrelsen (10000 bytes) i fravær af lignende restriktioner i NSS (mange strukturer i normal tilstand kunne have en størrelse på mere end 10000 bytes, så flere inputdata var påkrævet for at identificere problemer) . For fuld verifikation skulle grænsen have været 224-1 bytes (16 MB), hvilket svarer til den maksimale certifikatstørrelse tilladt i TLS.
- Misforståelse om fuzz-testkodedækning. Den sårbare kode blev aktivt testet, men ved hjælp af fuzzere, der ikke var i stand til at generere de nødvendige inputdata. For eksempel brugte fuzzer tls_server_target et foruddefineret sæt af færdiglavede certifikater, som begrænsede certifikatbekræftelseskodekontrollen til kun TLS-meddelelser og protokoltilstandsændringer.
Kilde: opennet.ru