Në paketën e bibliotekave kriptografike NSS (Shërbimet e Sigurisë Dritare), të zhvilluara nga kompania Mozilla, është zbuluar një vulnerabilitet kritik (CVE-2021-43527), i cili mund të çojë në ekzekutimin e kodit nga agresori gjatë përpunimit të nënshkrimeve digjitale DSA ose RSA-PSS, të caktuara me metodën e kodimit DER (Rregullat e Kodimit të Distinguar). Problemi, i cili ka marrë emrin kodor BigSig, është zgjidhur në versionet NSS 3.73 dhe NSS ESR 3.68.1. Përditësimet e paketave janë në dispozicion për distribucione si Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Për momentin nuk ka përditësime për Fedora.
Problemi shfaqet në aplikacionet që përdorin NSS për përpunimin e nënshkrimeve digjitale CMS, S/MIME, PKCS #7 dhe PKCS #12, ose gjatë verifikimit të certifikatave në implementime TLS, X.509, OCSP dhe CRL. Vulnerabiliteti mund të shfaqet në aplikacione të ndryshme klient/serwer me mbështetje TLS, DTLS dhe S/MIME, si klientët e postës elektronike dhe shikuesit PDF që përdorin thirrjen NSS CERT_VerifyCertificate() për të verifikuar nënshkrimet digjitale.
Si shembuj të aplikacioneve vulnerabël përmendet LibreOffice, Evolution dhe Evince. Problemi potencialisht mund të prekë gjithashtu projekte të tilla si Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss për serverin http Apache, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Megjithatë, vulnerabiliteti nuk shfaqet në Firefox, Thunderbird dhe Tor Browser, të cilat për verifikimin përdorin një bibliotekë të veçantë mozilla::pkix, e cila gjithashtu është pjesë e NSS. Problemi nuk prek as shfletuesit e bazuar në Chromium (nëse ato nuk janë ndërtuar posaçërisht me NSS), të cilët përdorën NSS deri në vitin 2015, por më pas u kaluan në BoringSSL.
Vulnerabiliteti shkaktohet nga një gabim në kodin e verifikimit të certifikatave në funksionin vfy_CreateContext nga skedari secvfy.c. Gabimi shfaqet si gjatë leximin nga klienti të certifikatave nga serveri, ashtu edhe gjatë përpunimit сервером të certifikatave të klientëve. Në procesin e verifikimit të nënshkrimit digjital, të koduar me metodën DER, NSS e dekodon nënshkrimin në një tampon me madhësi fikse dhe ia dërgon këtë tampon modulit PKCS #11. Gjatë përpunimit të mëtejshëm, për nënshkrimet DSA dhe RSA-PSS, nuk kontrollohet saktësisht madhësia, duke çuar në tejkalimin e tamponit të ndarë për strukturën VFYContextStr, nëse madhësia e nënshkrimit digjital tejkalon 16384 bit (për tamponin ndahen 2048 byte, por nuk kontrollohet se nënshkrimi mund të ketë një madhësi më të madhe).
Kodi që përmban vulnerabilitet është ndjekur që nga viti 2003, por nuk përbënte një kërcënim deri në rifaktorizimin e bërë në vitin 2012. Në vitin 2017, gjatë realizimit të mbështetjes RSA-PSS, u bë e njëjta gabim. Për të kryer një sulm, nuk kërkohet prodhimi i rëndë i çelësave të caktuar për të marrë të dhënat e nevojshme, pasi mbushja ndodh në fazën para verifikimit të nënshkrimit digjital. Pjesa e dhënave që del jashtë kufijve shkruhet në zonën e memories që përmban tregues për funksionet, duke e bërë krijimin e eksploitëve të funksionojnë më të lehtë.
Vulnerabiliteti u identifikua nga kërkuesit e Google Project Zero gjatë eksperimentimeve me metoda të reja të testimit fuzzing dhe është një shembull i shkëlqyer se si vulnerabilitetet triviale mund të mbeten të paqena për një kohë të gjatë në një projekt të njohur dhe të testuar gjerësisht:
- Kodi NSS mbështetet nga një ekip profesionistësh që merren me sigurinë, duke aplikuar metoda moderne të testimit dhe analizës së gabimeve. Ka disa programe për shpërblime të konsiderueshme për identifikimin e vulnerabiliteteve në NSS.
- NSS ishte një nga projektet e para që iu bashkua iniciativës Google oss-fuzz dhe gjithashtu u testua në sistemin e fuzzing-të zhvilluar nga Mozilla, duke përdorur libFuzzer.
- Kodi i bibliotekës është verifikuar shumë herë në analizatorët e ndryshëm statikë, duke përfshirë shërbimin Coverity që i ka ndjekur që nga viti 2008.
- Derisa në vitin 2015, NSS u përdor në Google Chrome dhe u testua në mënyrë të pavarur nga Mozilla nga ekipi i Google (që nga viti 2015, Chrome kaloi në BoringSSL, por mbështetje për portin e bazuar në NSS vazhdon).
Problemet kryesore që e bënë këtë çështje të mbetet për një kohë të gjatë të paqenë:
- NSS është një bibliotekë modulare dhe testimi fuzzing nuk u realizua në tërësi, por në nivel të komponentëve të veçantë. Për shembull, u kontrollua veçmas kodi i dekodimit të DER dhe përpunimit të çertifikatave - gjatë fuzzing-ut mund të ishte marrë një çertifikatë që çonte në shfaqjen e vulnerabilitetit të shqyrtuar, por verifikimi i saj nuk arrinte deri në kodin e verifikimit dhe problemi nuk e identifikonte veten.
- Gjatë testimit fuzzing, u vendosën kufij të rreptë mbi madhësinë e output-it (10000 byte) ndërsa nuk kishte kufij të tillë në NSS (shumë struktura mund të kishin një madhësi më të madhe se 10000 byte në funksionimin normal, prandaj kërkohej një volum më i madh të të dhënave hyrëse për të identifikuar problemet). Për një verifikim të plotë, kufiri duhet të ishte 224-1 byte (16 MB), që korrespondon me madhësinë maksimale të certifikatës që lejohet në TLS.
- E përfaqësuar gabim rreth mbulimit të kodit në testimin fuzzing. Kodi i rrezikshëm u testua aktivisht, por me përdorimin e fuzzer-ave që nuk ishin në gjendje të gjeneronin të dhënat hyrëse të nevojshme. Për shembull, fuzzer tls_server_target përdori një grup të paracaktuar të certifikatave, gjë që kufizoi kontrollin e kodit të verifikimit të certifikatës vetëm në mesazhet TLS dhe ndryshimet e gjendjes së protokollit.
Burimi: opennet.ru
