Mozilla väljatöötatud krüptograafiliste teekide NSS (Network Security Services) komplektis on tuvastatud kriitiline haavatavus (CVE-2021-43527), mis võib viia ründaja koodi käivitamiseni DSA või RSA-PSS digitaalallkirjade töötlemisel, mis on määratud DER-kodeeringu meetod ( Distinguished Encoding Rules). Probleem, koodnimega BigSig, on lahendatud versioonides NSS 3.73 ja NSS ESR 3.68.1. Distributsioonide paketivärskendused on saadaval Debiani, RHELi, Ubuntu, SUSE, Arch Linuxi, Gentoo ja FreeBSD jaoks. Fedora jaoks pole veel värskendusi saadaval.
Probleem ilmneb rakendustes, mis kasutavad NSS-i CMS-i, S/MIME-i, PKCS #7 ja PKCS #12 digitaalallkirjade haldamiseks või sertifikaatide kontrollimisel TLS-i, X.509-, OCSP- ja CRL-rakendustes. Haavatavus võib ilmneda erinevates kliendi- ja serverirakendustes, mis toetavad TLS-i, DTLS-i ja S/MIME-d, meiliklientides ja PDF-vaaturites, mis kasutavad digitaalallkirjade kontrollimiseks NSS-i CERT_VerifyCertificate()-kutset.
Haavatavate rakenduste näidetena on mainitud LibreOffice’i, Evolutionit ja Evince’i. Võimalik, et probleem võib mõjutada ka selliseid projekte nagu Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss Apache http-serveri jaoks, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Haavatavus ei ilmu aga Firefoxis, Thunderbirdis ja Tor-brauseris, mis kasutavad kontrollimiseks eraldi mozilla::pkix teeki, mis sisaldub ka NSS-is. Probleem ei puuduta ka kroomipõhiseid brausereid (välja arvatud juhul, kui need on spetsiaalselt NSS-iga ehitatud), mis kasutasid NSS-i kuni 2015. aastani, kuid läksid seejärel üle BoringSSL-ile.
Haavatavuse põhjuseks on faili secvfy.c funktsiooni vfy_CreateContext sertifikaadi kinnituskoodi viga. Viga ilmneb nii siis, kui klient loeb serverist sertifikaati, kui ka siis, kui server töötleb kliendi sertifikaate. DER-kodeeritud digitaalallkirja kontrollimisel dekodeerib NSS allkirja fikseeritud suurusega puhvrisse ja edastab puhvri PKCS #11 moodulile. Edasisel töötlemisel kontrollitakse suurust valesti DSA ja RSA-PSS allkirjade osas, mis viib struktuuri VFYContextStr jaoks eraldatud puhvri ületäitumiseni, kui digiallkirja suurus ületab 16384 bitti (puhvri jaoks eraldatakse 2048 baiti, kuid ei kontrollita, kas allkiri võib olla suurem) ).
Haavatavust sisaldav kood pärineb aastast 2003, kuid see ei kujutanud endast ohtu kuni 2012. aastal läbi viidud ümberkujundamiseni. 2017. aastal tehti sama viga RSA-PSS toe rakendamisel. Rünnaku läbiviimiseks ei ole vajalike andmete saamiseks vaja teatud võtmeid ressursimahukat genereerida, kuna ületäitumine toimub etapis enne digitaalallkirja õigsuse kontrollimist. Andmete osa, mis läheb üle piiride, kirjutatakse funktsioonide viiteid sisaldavale mälualale, mis lihtsustab töötavate exploitide loomist.
Haavatavuse avastasid Google Project Zero teadlased, katsetades uusi segaseid testimismeetodeid. See on hea näide sellest, kuidas triviaalsed haavatavused võivad laialdaselt testitud tuntud projektis pikka aega avastamata jääda:
- NSS-koodi haldab kogenud turvameeskond, kes kasutab nüüdisaegseid testimis- ja veaanalüüsi tehnikaid. NSS-i haavatavuste tuvastamise eest märkimisväärse tasu maksmiseks on olemas mitu programmi.
- NSS oli üks esimesi projekte, mis liitus Google'i oss-fuzzi algatusega ja seda testiti ka Mozilla libFuzzer-põhises fuzzi testimissüsteemis.
- Raamatukogu koodi on erinevates staatilistes analüsaatorites korduvalt kontrollitud, sealhulgas on seda jälgitud Coverity teenuse poolt alates 2008. aastast.
- Kuni 2015. aastani kasutati Google Chrome'is NSS-i ja Google'i tiim kinnitas selle sõltumatult Mozillast sõltumatult (alates 2015. aastast läks Chrome üle BoringSSL-ile, kuid NSS-põhise pordi tugi jääb alles).
Peamised probleemid, mille tõttu probleem jäi pikka aega avastamata:
- NSS-i moodulteek ja fuzzing-testimine viidi läbi mitte tervikuna, vaid üksikute komponentide tasemel. Näiteks kontrolliti eraldi koodi DER dekodeerimiseks ja sertifikaatide töötlemiseks - fuzzimise käigus oleks võinud saada sertifikaadi, mis viiks kõnealuse haavatavuse avaldumiseni, kuid selle kontroll ei jõudnud kontrollkoodini ja probleem ei ilmnenud. ennast paljastada.
- Hägustestimise ajal kehtestati ranged piirangud väljundi suurusele (10000 10000 baiti), kuna NSS-is sarnaseid piiranguid ei olnud (paljude tavarežiimis olevate struktuuride suurus võis olla suurem kui 224 1 baiti, seega oli probleemide tuvastamiseks vaja rohkem sisendandmeid) . Täielikuks kontrollimiseks oleks pidanud piirang olema 16-XNUMX baiti (XNUMX MB), mis vastab TLS-is lubatud maksimaalsele sertifikaadi suurusele.
- Väärarvamus fuzz-testi koodi katvuse kohta. Haavatavat koodi testiti aktiivselt, kuid kasutati fuzzereid, mis ei suutnud vajalikke sisendandmeid genereerida. Näiteks fuzzer tls_server_target kasutas eelnevalt määratletud valmissertifikaatide komplekti, mis piiras sertifikaadi kinnituskoodi kontrolli ainult TLS-sõnumite ja protokolli oleku muutustega.
Allikas: opennet.ru