Vulnerability in Mozilla NSS allows code execution when processing certificates

Mozilla arendatud NSS (Network Security Services) krüptograafiliste teekide komplektis tuvastati kriitiline haavatavus (CVE-2021-43527), mis võib võimaldada ründajal koodi täitmist DSA või RSA-PSS digitaalsete allkirjade töötlemisel, mis on määratud DER (Distinguished Encoding Rules) kodeerimismeetodi kasutamisega. Probleem, mille koodinimi on BigSig, on kõrvaldatud NSS 3.73 ja NSS ESR 3.68.1 väljaannetes. Pakettide uuendused jaotustes on saadaval Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD jaoks. Fedora jaoks uuendused ei ole veel saadaval.

Probleem ilmneb rakendustes, mis kasutavad NSS-i digitaalsete allkirjade CMS, S/MIME, PKCS #7 ja PKCS #12 töötlemiseks või sertifikaatide kontrollimiseks TLS, X.509, OCSP ja CRL rakendustes. Haavatavus võib ilmneda erinevates kliendi- ja serverirakendustes, mis toetavad TLS, DTLS ja S/MIME, e-posti klientides ja PDF-vaatamisprogrammides, mis kasutavad NSS-kutset CERT_VerifyCertificate() digitaalsete allkirjade kontrollimiseks.

Näitena haavatavatest rakendustest mainitakse LibreOffice'i, Evolutioni ja Evince'i. Potentsiaalselt võivad probleem mõjutada ka projekte nagu Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss Apache HTTP serverile, Oracle Communications Messaging Server ja Oracle Directory Server Enterprise Edition. Samuti ei avaldu haavatavus Firefoxis, Thunderbirdis ja Tor Browseris, kus valideerimiseks kasutatakse eraldi teeki mozilla::pkix, mis kuulub samuti NSS-i. Probleem ei puuduta ka Chromiumi põhiseid brausereid (kui need ei ole spetsiaalselt kokku pandud NSS-iga), mis kasutasid NSS-i kuni 2015. aastani, kuid on seejärel üle läinud BoringSSL-ile.

Haavatavus on põhjustatud tõrkest sertifikaatide valideerimise kontrollikoodis funktsioonis vfy_CreateContext failis secvfy.c. Tõrge ilmneb nii kliendi sertifikaadi lugemisel serverist kui ka töötlemisel. serveriga klientide sertifikaate. Digitaalse allkirja kontrollimise käigus, mis on kodeeritud DER-meetodil, dekodeerib NSS allkirja fikseeritud suurusega puhvri ja edastab selle PKCS #11 moodulisse. Edasise töötlemise käigus kontrollitakse DSA ja RSA-PSS allkiri puhul suurust vääralt, mis viib mälupuhvri ülevooluni, mis on ette nähtud VFYContextStr struktuuri jaoks, kui digitaalne allkiri ületab 16384 bitti (mälupuhvrile on eraldatud 2048 baiti, aga ei kontrollita, et allkiri võib olla suurem).

Haavatavusega kood on tuvastatud alates 2003. aastast, kuid see ei ole kujutanud ohtu enne 2012. aastal tehtud refaktoreerimist. 2017. aastal RSA-PSS toe rakendamisel tehti sama viga. Rünnaku teostamiseks ei ole vaja ressursimahukat kindlate võtmete genereerimist vajalike andmete saamiseks, kuna ülevool toimub allkirja õigsuse kontrollimise enne. Ülemäärased andmed kirjutatakse mälu osasse, mis sisaldab funktsioonide silte, mis lihtsustab töötavate eksploitide loomist.

Haavatavus avastati Google Project Zero uurijate poolt uute fuzzimislausete testimise meetodite katsetamise käigus ja see on hea näide sellest, kuidas laialdaselt testitud tuntud projektis võivad triviaalne haavatavused pikka aega märkamata jääda:

• NSS-i koodi toetab kogenud meeskond, kes vastutab turvalisuse ja rakendab modernseid testimis- ja vigade analüüsi meetodeid. Töötavad mitmed programmid, mis pakuvad olulisi preemiaid NSS-is leiduvate haavatavuste avastamise eest.
• NSS oli üks esimesi projekte, mis liitus Google'i oss-fuzz algatusega ja seda testiti ka Mozilla arendatavas fuzzimistestimise süsteemis libFuzzeri baasil.
• Raamatukogu kood on korduvalt kontrollitud erinevate staatiliste analüsaatorite poolt, sealhulgas on alates 2008. aastast jälginud Coverity teenus.
• Kuni 2015. aastani kasutati NSS-i Google Chrome'is ja sõltumatult Mozilla poolt kontrollis seda Google'i meeskond (alates 2015. aastast on Chrome üle läinud BoringSSL-ile, kuid NSS-põhise sadama tugi püsib).

Peamised probleemid, miks probleem pikka aega tähelepanuta jäi:

• NSS moodulaarne teek ja fuzzing-testimine viidi läbi mitte tervikuna, vaid üksikute komponentide tasandil. Näiteks kontrolliti eraldi DER dekodeerimise koodi ja sertifikaatide töötlemist — fuzzing-i käigus oleks võinud saada sertifikaadi, mis viib uuritava haavatavuse ilminguni, kuid selle kontroll ei jõudnud verifitseerimise koodini ning probleem ei avaldunud.
• Fuzzing-testimise käigus kehtestati väljundi suurusele ranged piirangud (10000 baiti), samas kui NSS-is selliseid piiranguid ei olnud (paljud struktuurid normaalses režiimis võisid olla suuremad kui 10000 baiti, seega probleemide tuvastamiseks oli vajalik suurem sisendandmete maht). Täielikuks kontrollimiseks pidi piirang olema 224-1 baiti (16 MB), mis vastab maksimaalsele sertifikaadi suurusele, mis on TLS-is lubatud.
• Vale arusaam fuzzing-testi katte ulatusest. Haavatav kood on aktiivselt testitud, kuid fuzzerite abil, mis ei suuda genereerida vajalikke sisendeid. Näiteks kasutas fuzzer tls_server_target eelnevalt määratud sertifikaatide komplekti, mis piiras sertifikaadi kontrollimise koodi validatsiooni ainult TLS- sõnumite ja protokolli oleku muutustega.

Allikas: opennet.ru