En kritisk sårbarhet (CVE-2021-43527) er identifisert i NSS-settet (Network Security Services) med kryptografiske biblioteker utviklet av Mozilla, som kan føre til kjøring av angriperkode ved behandling av digitale DSA- eller RSA-PSS-signaturer spesifisert ved hjelp av DER-kodingsmetode (Distinguished Encoding Rules). Problemet, kodenavnet BigSig, er løst i NSS 3.73 og NSS ESR 3.68.1. Pakkeoppdateringer i distribusjoner er tilgjengelige for Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Det er ingen tilgjengelige oppdateringer for Fedora ennå.
Problemet oppstår i applikasjoner som bruker NSS til å håndtere CMS, S/MIME, PKCS #7 og PKCS #12 digitale signaturer, eller ved verifisering av sertifikater i TLS, X.509, OCSP og CRL implementeringer. Sårbarheten kan dukke opp i ulike klient- og serverapplikasjoner som støtter TLS, DTLS og S/MIME, e-postklienter og PDF-lesere som bruker NSS CERT_VerifyCertificate()-kallet for å bekrefte digitale signaturer.
LibreOffice, Evolution og Evince nevnes som eksempler på sårbare applikasjoner. Potensielt kan problemet også påvirke prosjekter som Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss for Apache http-serveren, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Sårbarheten vises imidlertid ikke i Firefox, Thunderbird og Tor Browser, som bruker et eget mozilla::pkix-bibliotek, også inkludert i NSS, for verifisering. Krombaserte nettlesere (med mindre de er spesifikt bygget med NSS), som brukte NSS frem til 2015, men deretter byttet til BoringSSL, er heller ikke berørt av problemet.
Sårbarheten er forårsaket av en feil i sertifikatverifiseringskoden i vfy_CreateContext-funksjonen fra secvfy.c-filen. Feilen oppstår både når klienten leser et sertifikat fra serveren og når serveren behandler klientsertifikater. Når du verifiserer en DER-kodet digital signatur, dekoder NSS signaturen til en buffer med fast størrelse og sender bufferen til PKCS #11-modulen. Under videre behandling kontrolleres størrelsen feil for DSA- og RSA-PSS-signaturer, noe som fører til overløp av bufferen som er tildelt for VFYContextStr-strukturen hvis størrelsen på den digitale signaturen overstiger 16384 biter (2048 byte er tildelt for bufferen, men det er ikke sjekket at signaturen kan være større) ).
Koden som inneholder sårbarheten kan spores tilbake til 2003, men den utgjorde ikke en trussel før en refaktorisering utført i 2012. I 2017 ble den samme feilen gjort ved implementering av RSA-PSS-støtte. For å utføre et angrep er det ikke nødvendig med ressurskrevende generering av visse nøkler for å skaffe de nødvendige dataene, siden overløpet skjer på stadiet før man kontrollerer riktigheten av den digitale signaturen. Den delen av dataene som går utover grensene skrives til et minneområde som inneholder pekere til funksjoner, noe som forenkler opprettelsen av arbeidsutnyttelser.
Sårbarheten ble oppdaget av forskere fra Google Project Zero mens de eksperimenterte med nye uklare testmetoder og er en god demonstrasjon av hvordan trivielle sårbarheter kan forbli uoppdaget i lang tid i et mye testet velkjent prosjekt:
- NSS-koden vedlikeholdes av et erfarent sikkerhetsteam ved hjelp av state-of-the-art testing og feilanalyseteknikker. Det er flere programmer på plass for å betale betydelige belønninger for å identifisere sårbarheter i NSS.
- NSS var et av de første prosjektene som ble med i Googles oss-fuzz-initiativ og ble også testet i Mozillas libFuzzer-baserte fuzz-testsystem.
- Bibliotekkoden har blitt sjekket mange ganger i forskjellige statiske analysatorer, inkludert å ha blitt overvåket av Coverity-tjenesten siden 2008.
- Fram til 2015 ble NSS brukt i Google Chrome og ble uavhengig verifisert av Google-teamet uavhengig av Mozilla (siden 2015 har Chrome byttet til BoringSSL, men støtte for den NSS-baserte porten er fortsatt).
De viktigste problemene som skyldes at problemet forble uoppdaget i lang tid:
- NSS modulære bibliotek og fuzzing-testing ble ikke utført som en helhet, men på nivået av individuelle komponenter. For eksempel ble koden for dekoding av DER og behandling av sertifikater sjekket separat - under fuzzing kunne et sertifikat ha blitt oppnådd som ville føre til manifestasjonen av den aktuelle sårbarheten, men kontrollen nådde ikke bekreftelseskoden og problemet nådde ikke avsløre seg selv.
- Under fuzzing-testing ble det satt strenge restriksjoner på utdatastørrelsen (10000 10000 byte) i fravær av lignende restriksjoner i NSS (mange strukturer i normal modus kunne ha en størrelse på mer enn 224 1 byte, så det var nødvendig med flere inndata for å identifisere problemer) . For full verifisering burde grensen vært 16-XNUMX byte (XNUMX MB), som tilsvarer den maksimale sertifikatstørrelsen som er tillatt i TLS.
- Misforståelse om fuzz-testkodedekning. Den sårbare koden ble aktivt testet, men ved bruk av fuzzere som ikke var i stand til å generere de nødvendige inndataene. For eksempel brukte fuzzer tls_server_target et forhåndsdefinert sett med ferdiglagde sertifikater, som begrenset sertifikatverifiseringskodekontrollen til kun TLS-meldinger og endringer i protokollstatus.
Kilde: opennet.ru