Mozillan kehittämässä NSS (Network Security Services) salauskirjastojoukossa on havaittu kriittinen haavoittuvuus (CVE-2021-43527), joka voi johtaa hyökkääjäkoodin suorittamiseen käsiteltäessä DSA- tai RSA-PSS-digitaaliallekirjoituksia, jotka on määritetty DER-koodausmenetelmä ( Distinguished Encoding Rules). Ongelma, koodinimeltään BigSig, on ratkaistu NSS 3.73:ssa ja NSS ESR 3.68.1:ssä. Jakelujen pakettipäivitykset ovat saatavilla Debianille, RHEL:lle, Ubuntulle, SUSElle, Arch Linuxille, Gentoolle ja FreeBSD:lle. Fedoralle ei ole vielä saatavilla päivityksiä.
Ongelma ilmenee sovelluksissa, jotka käyttävät NSS:ää CMS:n, S/MIME:n, PKCS #7:n ja PKCS #12:n digitaalisten allekirjoitusten käsittelyyn, tai kun varmenteita tarkistetaan TLS-, X.509-, OCSP- ja CRL-toteutuksissa. Haavoittuvuus voi ilmetä erilaisissa asiakas- ja palvelinsovelluksissa, jotka tukevat TLS:ää, DTLS:ää ja S/MIME:tä, sähköpostiohjelmissa ja PDF-katseluohjelmissa, jotka käyttävät NSS CERT_VerifyCertificate() -kutsua digitaalisten allekirjoitusten vahvistamiseen.
LibreOffice, Evolution ja Evince mainitaan esimerkkeinä haavoittuvista sovelluksista. Mahdollisesti ongelma voi vaikuttaa myös projekteihin, kuten Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss Apache http -palvelimelle, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Haavoittuvuus ei kuitenkaan esiinny Firefoxissa, Thunderbirdissä ja Tor Browserissa, jotka käyttävät erillistä mozilla::pkix-kirjastoa, joka sisältyy myös NSS:ään, vahvistukseen. Ongelma ei myöskään vaikuta kromipohjaisiin selaimiin (elleivät ne ole erityisesti rakennettu NSS:llä), jotka käyttivät NSS:ää vuoteen 2015 asti, mutta siirtyivät sitten BoringSSL:ään.
Haavoittuvuus johtuu virheestä sertifikaatin vahvistuskoodissa vfy_CreateContext-funktiossa secvfy.c-tiedostosta. Virhe ilmenee sekä kun asiakas lukee varmenteen palvelimelta että kun palvelin käsittelee asiakasvarmenteita. Vahvistaessaan DER-koodattua digitaalista allekirjoitusta NSS purkaa allekirjoituksen kiinteän kokoiseksi puskuriksi ja välittää puskurin PKCS #11 -moduulille. Jatkokäsittelyn aikana koko tarkistetaan virheellisesti DSA- ja RSA-PSS-allekirjoitusten varalta, mikä johtaa VFYContextStr-rakenteelle varatun puskurin ylivuotoon, jos digitaalisen allekirjoituksen koko ylittää 16384 bittiä (puskurille varataan 2048 tavua, mutta ei ole tarkistettu, että allekirjoitus voi olla suurempi) ).
Haavoittuvuuden sisältävä koodi voidaan jäljittää vuodelle 2003, mutta se ei aiheuttanut uhkaa ennen vuonna 2012 suoritettua uudelleenjärjestelyä. Vuonna 2017 tehtiin sama virhe RSA-PSS-tuen käyttöönotossa. Hyökkäyksen toteuttaminen ei vaadi resurssiintensiivistä tiettyjen avainten luomista tarvittavien tietojen saamiseksi, koska ylivuoto tapahtuu vaiheessa ennen digitaalisen allekirjoituksen oikeellisuuden tarkistamista. Rajat ylittävä osa tiedosta kirjoitetaan muistialueelle, joka sisältää viitteitä funktioihin, mikä yksinkertaistaa toimivien hyödykkeiden luomista.
Google Project Zeron tutkijat löysivät haavoittuvuuden kokeillessaan uusia hämmentäviä testausmenetelmiä, ja se on hyvä osoitus siitä, kuinka triviaaleja haavoittuvuuksia ei havaita pitkään aikaan laajasti testatussa tunnetussa projektissa:
- NSS-koodia ylläpitää kokenut turvallisuustiimi, joka käyttää huippuluokan testaus- ja virheanalyysitekniikoita. On olemassa useita ohjelmia, joilla voidaan maksaa merkittäviä palkintoja NSS:n haavoittuvuuksien tunnistamisesta.
- NSS oli yksi ensimmäisistä projekteista, jotka liittyivät Googlen oss-fuzz-aloitteeseen, ja sitä testattiin myös Mozillan libFuzzer-pohjaisessa fuzz-testausjärjestelmässä.
- Kirjaston koodia on tarkastettu useaan otteeseen erilaisissa staattisissa analysaattoreissa, muun muassa Coverity-palvelun seurannassa vuodesta 2008 lähtien.
- Vuoteen 2015 asti Google Chromessa käytettiin NSS:ää, ja Google-tiimi vahvisti sen itsenäisesti Mozillasta riippumatta (vuodesta 2015 Chrome siirtyi BoringSSL:ään, mutta NSS-pohjaisen portin tuki säilyy).
Tärkeimmät ongelmat, joiden vuoksi ongelma jäi havaitsematta pitkään:
- NSS-moduulikirjastoa ja fuzzing-testausta ei suoritettu kokonaisuutena, vaan yksittäisten komponenttien tasolla. Esimerkiksi DER-koodauksen ja varmenteiden käsittelyn koodi tarkistettiin erikseen - fuzzingin aikana olisi voitu saada varmenne, joka johtaisi kyseisen haavoittuvuuden ilmenemiseen, mutta sen tarkistus ei päässyt vahvistuskoodiin eikä ongelma ilmennyt. paljastaa itsensä.
- Fuzzing-testauksen aikana tulostekoon (10000 10000 tavua) asetettiin tiukat rajoitukset, koska NSS:ssä ei ollut vastaavia rajoituksia (monien normaalitilassa olevien rakenteiden koko saattoi olla yli 224 1 tavua, joten ongelmien tunnistamiseen tarvittiin enemmän syöttötietoja) . Täydellistä todentamista varten rajan olisi pitänyt olla 16-XNUMX tavua (XNUMX Mt), mikä vastaa TLS:ssä sallittua suurinta varmenteen kokoa.
- Väärä käsitys fuzz-testauskoodin kattavuudesta. Haavoittuvaa koodia testattiin aktiivisesti, mutta käyttämällä fuzzereja, jotka eivät pystyneet luomaan tarvittavaa syöttödataa. Esimerkiksi fuzzer tls_server_target käytti ennalta määritettyä joukkoa valmiita varmenteita, mikä rajoitti varmenteen vahvistuskoodin tarkistuksen vain TLS-sanomiin ja protokollan tilan muutoksiin.
Lähde: opennet.ru