Ranjivost izvršavanja koda u Mozilla NSS pri obradi certifikata

Kritična ranjivost (CVE-2021-43527) identifikovana je u NSS (Network Security Services) skupu kriptografskih biblioteka koje je razvila Mozilla, a koja može dovesti do izvršenja napadačkog koda prilikom obrade DSA ili RSA-PSS digitalnih potpisa navedenih pomoću DER metoda kodiranja (Distinguished Encoding Rules). Problem, kodnog naziva BigSig, riješen je u NSS 3.73 i NSS ESR 3.68.1. Ažuriranja paketa u distribucijama su dostupna za Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Još uvijek nema dostupnih ažuriranja za Fedoru.

Problem se javlja u aplikacijama koje koriste NSS za rukovanje digitalnim potpisima CMS, S/MIME, PKCS #7 i PKCS #12 ili prilikom provjere certifikata u TLS, X.509, OCSP i CRL implementacijama. Ranjivost se može pojaviti u različitim klijentskim i serverskim aplikacijama koje podržavaju TLS, DTLS i S/MIME, klijentima e-pošte i PDF pregledačima koji koriste NSS CERT_VerifyCertificate() poziv za provjeru digitalnih potpisa.

LibreOffice, Evolution i Evince spominju se kao primjeri ranjivih aplikacija. Potencijalno, problem može uticati i na projekte kao što su Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss za Apache http server, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Međutim, ranjivost se ne pojavljuje u Firefoxu, Thunderbirdu i Tor Browseru, koji koriste zasebnu mozilla::pkix biblioteku, također uključenu u NSS, za verifikaciju. Chromium-bazirani pretraživači (osim ako nisu posebno napravljeni sa NSS-om), koji su koristili NSS do 2015. godine, ali su potom prešli na BoringSSL, također nisu pogođeni problemom.

Ranjivost je uzrokovana greškom u kodu za provjeru certifikata u funkciji vfy_CreateContext iz datoteke secvfy.c. Greška se javlja i kada klijent čita certifikat sa servera i kada server obrađuje klijentske sertifikate. Prilikom provjere digitalnog potpisa kodiranog DER-om, NSS dekodira potpis u bafer fiksne veličine i prosljeđuje bafer PKCS #11 modulu. Tokom dalje obrade, veličina se neispravno provjerava za DSA i RSA-PSS potpise, što dovodi do prekoračenja bafera dodijeljenog za strukturu VFYContextStr ako veličina digitalnog potpisa prelazi 16384 bita (2048 bajtova je dodijeljeno za bafer, ali ne provjerava se da potpis može biti veći) ).

Kod koji sadrži ranjivost može se pratiti do 2003. godine, ali nije predstavljao prijetnju sve do refaktoriranja izvršenog 2012. godine. U 2017. godini je napravljena ista greška prilikom implementacije RSA-PSS podrške. Da bi se izvršio napad, nije potrebno generiranje određenih ključeva koji zahtijevaju velike resurse da bi se dobili potrebni podaci, jer se prelijevanje događa u fazi prije provjere ispravnosti digitalnog potpisa. Dio podataka koji prelazi granice se upisuje u memorijsku oblast koja sadrži pokazivače na funkcije, što pojednostavljuje kreiranje radnih eksploata.

Ranjivost su otkrili istraživači iz Google Project Zero eksperimentirajući s novim metodama fuzzing testiranja i dobra je demonstracija kako trivijalne ranjivosti mogu ostati neotkrivene dugo vremena u naširoko testiranom poznatom projektu:

  • NSS kod održava iskusan sigurnosni tim koristeći najsavremenije tehnike testiranja i analize grešaka. Postoji nekoliko programa za plaćanje značajnih nagrada za identifikovanje ranjivosti u NSS.
  • NSS je bio jedan od prvih projekata koji se pridružio Guglovoj oss-fuzz inicijativi i takođe je testiran u Mozilla-inom libFuzzer-baziranom sistemu fuzz testiranja.
  • Kôd biblioteke je provjeren mnogo puta u raznim statičkim analizatorima, uključujući i praćenje od strane Coverity servisa od 2008. godine.
  • Do 2015. godine, NSS se koristio u Google Chrome-u i neovisno ga je verifikovao Google tim nezavisno od Mozille (od 2015. Chrome je prešao na BoringSSL, ali podrška za NSS-bazirani port ostaje).

Glavni problemi zbog kojih je problem dugo vremena ostao neotkriven:

  • NSS modularna biblioteka i fuzing testiranje su sprovedeni ne kao celina, već na nivou pojedinačnih komponenti. Na primjer, kod za dekodiranje DER i za obradu certifikata je provjeren odvojeno - tokom fuzinga mogao se dobiti certifikat koji bi doveo do ispoljavanja predmetne ranjivosti, ali njegova provjera nije stigla do verifikacionog koda i problem nije riješen. otkriti se.
  • Tokom fuzzing testiranja, postavljena su stroga ograničenja na izlaznu veličinu (10000 bajtova) u odsustvu sličnih ograničenja u NSS-u (mnoge strukture u normalnom režimu mogu imati veličinu veću od 10000 bajtova, tako da je bilo potrebno više ulaznih podataka da bi se identifikovali problemi) . Za potpunu verifikaciju, ograničenje je trebalo biti 224-1 bajta (16 MB), što odgovara maksimalnoj veličini certifikata dozvoljenoj u TLS-u.
  • Zabluda o pokrivenosti koda fuzz testiranjem. Ranjivi kod je aktivno testiran, ali koristeći fuzzere koji nisu bili u stanju da generišu potrebne ulazne podatke. Na primjer, fuzzer tls_server_target je koristio unaprijed definirani skup gotovih certifikata, koji je ograničio provjeru koda za provjeru certifikata samo na TLS poruke i promjene stanja protokola.

izvor: opennet.ru

Dodajte komentar