'n Kritieke kwesbaarheid (CVE-2021-43527) is geïdentifiseer in die NSS (Network Security Services) stel kriptografiese biblioteke wat deur Mozilla ontwikkel is, wat kan lei tot die uitvoering van aanvallerkode wanneer DSA- of RSA-PSS digitale handtekeninge verwerk word wat gespesifiseer is met behulp van die DER-koderingsmetode (Distinguished Encoding Rules). Die probleem, met die kodenaam BigSig, word opgelos in NSS 3.73 en NSS ESR 3.68.1. Pakketopdaterings in verspreidings is beskikbaar vir Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Daar is nog geen opdaterings vir Fedora beskikbaar nie.
Die probleem kom voor in toepassings wat NSS gebruik om CMS, S/MIME, PKCS #7 en PKCS #12 digitale handtekeninge te hanteer, of wanneer sertifikate in TLS-, X.509-, OCSP- en CRL-implementerings geverifieer word. Die kwesbaarheid kan verskyn in verskeie kliënt- en bedienertoepassings wat TLS, DTLS en S/MIME ondersteun, e-poskliënte en PDF-kykers wat die NSS CERT_VerifyCertificate()-oproep gebruik om digitale handtekeninge te verifieer.
LibreOffice, Evolution en Evince word genoem as voorbeelde van kwesbare toepassings. Die probleem kan moontlik ook projekte soos Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss vir die Apache http-bediener, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition, beïnvloed. Die kwesbaarheid verskyn egter nie in Firefox, Thunderbird en Tor-blaaier nie, wat 'n aparte mozilla::pkix-biblioteek gebruik, wat ook by NSS ingesluit is, vir verifikasie. Chroom-gebaseerde blaaiers (tensy hulle spesifiek met NSS gebou is), wat NSS tot 2015 gebruik het, maar toe na BoringSSL oorgeskakel het, word ook nie deur die probleem geraak nie.
Die kwesbaarheid word veroorsaak deur 'n fout in die sertifikaatverifikasiekode in die vfy_CreateContext-funksie vanaf die secvfy.c-lêer. Die fout vind plaas wanneer die kliënt 'n sertifikaat vanaf die bediener lees en wanneer die bediener kliëntsertifikate verwerk. Wanneer 'n DER-gekodeerde digitale handtekening geverifieer word, dekodeer NSS die handtekening in 'n vaste-grootte buffer en stuur die buffer na die PKCS #11 module. Tydens verdere verwerking word die grootte verkeerdelik nagegaan vir DSA- en RSA-PSS-handtekeninge, wat lei tot 'n oorloop van die buffer wat vir die VFYContextStr-struktuur toegewys is as die grootte van die digitale handtekening 16384 bisse oorskry (2048 grepe word vir die buffer toegeken, maar daar word nie gekontroleer dat die handtekening groter kan wees nie) ).
Die kode wat die kwesbaarheid bevat, kan teruggevoer word na 2003, maar dit het nie 'n bedreiging ingehou totdat 'n herfaktorering in 2012 uitgevoer is nie. In 2017 is dieselfde fout gemaak met die implementering van RSA-PSS-ondersteuning. Om 'n aanval uit te voer, is hulpbron-intensiewe generering van sekere sleutels nie nodig om die nodige data te verkry nie, aangesien die oorloop plaasvind op die stadium voordat die korrektheid van die digitale handtekening gekontroleer word. Die deel van die data wat oor die grense gaan, word na 'n geheue-area geskryf wat wysers na funksies bevat, wat die skepping van werkende uitbuitings vergemaklik.
Die kwesbaarheid is ontdek deur navorsers van Google Project Zero terwyl hulle eksperimenteer met nuwe fuzzing toetsmetodes en is 'n goeie demonstrasie van hoe onbenullige kwesbaarhede vir 'n lang tyd onopgemerk kan bly in 'n wyd getoets bekende projek:
- Die NSS-kode word in stand gehou deur 'n ervare sekuriteitspan wat die nuutste toets- en foutontledingstegnieke gebruik. Daar is verskeie programme in plek om aansienlike belonings te betaal vir die identifisering van kwesbaarhede in NSS.
- NSS was een van die eerste projekte wat by Google se oss-fuzz-inisiatief aangesluit het en is ook in Mozilla se libFuzzer-gebaseerde fuzz-toetsstelsel getoets.
- Die biblioteekkode is al baie keer in verskeie statiese ontleders nagegaan, insluitend dat dit sedert 2008 deur die Coverity-diens gemonitor word.
- Tot 2015 is NSS in Google Chrome gebruik en is onafhanklik deur die Google-span onafhanklik van Mozilla geverifieer (sedert 2015 het Chrome na BoringSSL oorgeskakel, maar ondersteuning vir die NSS-gebaseerde poort bly steeds).
Die hoofprobleme waardeur die probleem vir 'n lang tyd onopgemerk gebly het:
- Die NSS modulêre biblioteek en fuzzing toetsing is nie as 'n geheel uitgevoer nie, maar op die vlak van individuele komponente. Byvoorbeeld, die kode vir dekodering van DER en verwerking van sertifikate is afsonderlik nagegaan - tydens fuzzing kon 'n sertifikaat verkry word wat sou lei tot die manifestasie van die betrokke kwesbaarheid, maar die kontrolering daarvan het nie die verifikasiekode bereik nie en die probleem het nie homself openbaar.
- Tydens fuzzing-toetsing is streng beperkings op die uitsetgrootte (10000 10000 grepe) gestel in die afwesigheid van soortgelyke beperkings in NSS (baie strukture in normale modus kan 'n grootte van meer as 224 1 grepe hê, dus was meer invoerdata nodig om probleme te identifiseer) . Vir volle verifikasie moes die limiet 16-XNUMX grepe (XNUMX MB) gewees het, wat ooreenstem met die maksimum sertifikaatgrootte wat in TLS toegelaat word.
- Wanopvatting oor fuzz-toetskode-dekking. Die kwesbare kode is aktief getoets, maar met behulp van fuzzers wat nie die nodige invoerdata kon genereer nie. Byvoorbeeld, fuzzer tls_server_target het 'n voorafbepaalde stel klaargemaakte sertifikate gebruik, wat die sertifikaatverifikasiekodekontrole beperk het tot slegs TLS-boodskappe en protokoltoestandveranderings.
Bron: opennet.ru