Haavatavus Mozilla NSS-is, mis võimaldab koodi käivitamist sertifikaatide töötlemise käigus

Mozilla'i arendatavates NSS (Network Security Services) krüptograafia raamatukogudes tuvastati kriitiline haavatavus (CVE-2021-43527), mis võib põhjustada ründaja koodi täitmist DSA või RSA-PSS digitaalsete allkirjade töötlemisel, mis on määratud DER (Distinguished Encoding Rules) koodimise meetodi abil. Probleem, mille koodinimi on BigSig, on lahendatud NSS versioonides 3.73 ja NSS ESR 3.68.1. Paketi uuendused on saadaval Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD distributsioonides. Fedora jaoks pole uuendusi veel saadaval.

Probleem ilmneb rakendustes, mis kasutavad NSS-i CMS, S/MIME, PKCS #7 ja PKCS #12 digitaalsete allkirjade töötlemiseks või sertifikaatide kinnitamiseks TLS, X.509, OCSP ja CRL rakendustes. Haavatavus võib esineda erinevates TLS, DTLS ja S/MIME toega kliendi- ja serverirakendustes, postiklientides ja PDF-vaatlejates, mis kasutavad NSS-i funktsiooni CERT_VerifyCertificate() digitaalsete allkirjade kontrollimiseks.

Haavatavate rakenduste näidetena nimetatakse LibreOffice'i, Evolutioni ja Evince'i. Potentsiaalselt võivad probleemist olla mõjutatud ka sellised projektid nagu Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss Apache http-server’y jaoks, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Samas ei ilmne haavatavus Firefoxis, Thunderbirdis ja Tor Browseris, kus kinnitamiseks kasutatakse eraldi raamatukogu mozilla::pkix, mis kuulub samuti NSS-i. Chromiumi põhised brauserid ei ole samuti haavatavad (kui neid ei ole spetsiaalselt NSS-iga kompileeritud), kuna nad kasutasid NSS-i kuni 2015. aastani, kuid seejärel viidi üle BoringSSL-ile.

Haavatavus tuleneb vea olemasolust sertifikaatide kinnitamise kontrolli koodis funktsioonis vfy_CreateContext failist secvfy.c. Vea ilmnemine on seotud nii kliendilt sertifikaadi lugemisega serverist kui ka töötlemisega. serverilt kliendi sertifikaatide puhul. Digitaalsete allkirjade kontrollimise protsessis, mis on kodeeritud DER-meetodi abil, dekodeerib NSS allkirja fikseeritud suurusega puhvri ja edastab selle PKCS #11 moodulile. Edasi töötlemisel, DSA ja RSA-PSS allkirjade puhul ei kontrollita suurust õigesti, mis toob kaasa puhverülekande VFYContextStr struktuuri jaoks, kui digitaalsete allkirjade suurus ületab 16384 bitti (puhvri jaoks on eraldatud 2048 baiti, kuid ei kontrollita, et allkiri võib olla suurem).

Haavatavusega kood on jälgitav alates 2003. aastast, kuid see ei olnud ohtlik kuni 2012. aastal toimunud refaktooringuni. 2017. aastal RSA-PSS toetuse juurutamisel tehti sama viga. Rünnaku tegemiseks ei ole vajalik ressursside intensiivne teatud võtmete genereerimine vajalike andmete saamiseks, kuna üleujutus toimub enne digitaalallkirja kehtivuse kontrollimist. Piiridest väljas olev osa andmeid kirjutatakse mälu-alasse, mis sisaldab funktsioonide näitajaid, mis lihtsustab töötavate eksploitide loomist.

Haavatavus tuvastati Google Project Zero teadlaste poolt uute fuzzing-testimise meetodite katsetamisel ja on hea näide sellest, kuidas laialdaselt testitud tuntud projekti sees võivad püsida triviaalsete haavatavuste jälgedes.

• NSS koodi toetab kogenud meeskond, kes vastutab turvalisuse eest ja rakendab kaasaegseid testimise ja vigade analüüsi meetodeid. Töötavad mitmed programmid, mis maksavad olulisi preemiaid NSS-is tuvastatud haavatavuste eest.
• NSS oli üks esimesi projekte, mis liitus Google'i oss-fuzzi algatusega ja seda testiti ka Mozilla arendatavas fuzzy-testeerimise süsteemis, mis põhineb libFuzzeril.
• Raamatukogu kood on korduvalt kontrollitud erinevates staatilistes analüüsijates, sealhulgas alates 2008. aastast Coverity teenuses.
• Kuni 2015. aastani kasutati NSS-i Google Chrome'is ja seda kontrolliti sõltumatult Mozilla meeskonna poolt (alates 2015. aastast on Chrome liikunud BoringSSL-i, kuid NSS-i põhine port jätkab toetust).

Põhiprobleemid, miks probleem kaua tähelepanuta jäi:

• NSS on moodulraamatukogu ja fuzzing-testimine toimus mitte tervikuna, vaid eraldi komponentide tasemel. Näiteks kontrolliti eraldi DER-dekodeerimise ja sertifikaatide töötlemise koodi — fuzzimise käigus võis kergesti saada sertifikaadi, mis viis vaadeldava haavatavuse väljendamiseni, kuid selle kontroll ei jõudnud verifikatsioonikoodini ja probleem ei avanenud.
• Fuzzing-testimise ajal kehtestati väljundi suurusele ranged piirangud (10000 bait), samas kui NSS-is ei olnud selliseid piiranguid (paljud struktuurid normaalses režiimis võisid olla suuremad kui 10000 bait, mistõttu probleemide avastamiseks oli vajalik suurem sisendandmete maht). Täielikuks kontrollimiseks pidi piir olema 224-1 baiti (16 MB), mis vastab TLS-is lubatud maksimaalsele sertifikaadi suurusele.
• Vale arusaam fuzzing-testimise kodekatte ulatusest. Haavatavat koodi testiti aktiivselt, kuid kasutati fuzzer'e, mis ei suutnud genereerida vajalikke sisendandmeid. Näiteks fuzzer tls_server_target kasutas etteantud komplekti valmis sertifikaate, mis piiras sertifikaadi verifitseerimise koodi kontrolli ainult TLS-sõnumitega ja protokolli olekumuutustega.

Allikas: opennet.ru