În setul de biblioteci criptografice NSS (Network Security Services), dezvoltate de Mozilla, a fost descoperită o vulnerabilitate critică (CVE-2021-43527), care poate permite executarea codului rău intenționat în timpul procesării semnăturilor digitale DSA sau RSA-PSS, specificate folosind metoda de codare DER (Distinguished Encoding Rules). Problema, denumită BigSig, a fost remediată în versiunile NSS 3.73 și NSS ESR 3.68.1. Actualizările pachetelor în distribuții sunt disponibile pentru Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Actualizările pentru Fedora nu sunt încă disponibile.
Problema apare în aplicațiile care utilizează NSS pentru procesarea semnăturilor digitale CMS, S/MIME, PKCS #7 și PKCS #12, sau în timpul verificării certificatelor în implementările TLS, X.509, OCSP și CRL. Vulnerabilitatea poate apărea în diverse aplicații client și server care suportă TLS, DTLS și S/MIME, în clienți de email și cititoare PDF care folosesc apelul NSS CERT_VerifyCertificate() pentru a verifica semnăturile digitale.
Printre aplicațiile vulnerabile se numără LibreOffice, Evolution și Evince. Potențial, problema poate afecta și proiecte precum Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss pentru serverul http Apache, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Totuși, vulnerabilitatea nu afectează Firefox, Thunderbird și Tor Browser, care folosesc o bibliotecă separată mozilla::pkix pentru verificare, parte integrantă a NSS. Browserele bazate pe Chromium nu sunt afectate (dacă nu au fost construite special cu NSS), care au folosit NSS până în 2015, dar care au fost ulterior migrate la BoringSSL.
Vulnerabilitatea este cauzată de o eroare în codul de verificare a certificatelor în funcția vfy_CreateContext din fișierul secvfy.c. Eroarea apare atât la citirea certificatului client de pe server, cât și în timpul procesării serverul certificatelor clienților. În timpul procesării semnăturii digitale, codificată prin metoda DER, NSS decodează semnătura într-un buffer de dimensiune fixă și transmite acest buffer modulului PKCS #11. În timpul procesării ulterioare, pentru semnăturile DSA și RSA-PSS, dimensiunea nu este verificată corect, ceea ce duce la overflow-ul buffer-ului alocat pentru structura VFYContextStr, dacă dimensiunea semnăturii digitale depășește 16384 biți (bufferul este alocat la 2048 octeți, dar nu este verificat că semnătura poate fi mai mare).
Codul vulnerabil este urmărit din 2003, însă nu a reprezentat o amenințare până la refactorizarea efectuată în 2012. În 2017, la implementarea suportului RSA-PSS, s-a comis aceeași greșeală. Pentru a desfășura un atac, nu este necesară generarea costisitoare din punct de vedere al resurselor a unor chei specifice pentru a obține datele necesare, deoarece depășirea are loc înainte de verificarea validității semnăturii digitale. Partea de date care depășește limitele este scrisă în zona de memorie care conține pointeurii funcțiilor, ceea ce simplifică crearea exploiturilor funcționale.
Vulnerabilitatea a fost identificată de cercetătorii de la Google Project Zero în timpul experimentelor cu noi metode de testare fuzzing și este o bună demonstrație a modului în care, într-un proiect cunoscut și bine testat, pot rămâne neobservate timp îndelungat vulnerabilități triviale:
- Codul NSS este însoțit de o echipă de experți responsabili pentru securitate, care aplică metode moderne de testare și analiză a erorilor. Există mai multe programe care oferă recompense substanțiale pentru identificarea vulnerabilităților în NSS.
- NSS a fost unul dintre primele proiecte care s-au alăturat inițiativei Google oss-fuzz și a fost, de asemenea, testat în sistemul de fuzzing-teste dezvoltat de Mozilla bazat pe libFuzzer.
- Codul bibliotecii a fost verificat de mai multe ori în diferite analizoare statice, inclusiv de serviciul Coverity care monitorizează din 2008.
- Până în 2015, NSS a fost utilizat în Google Chrome și, independent de Mozilla, a fost verificat de echipa Google (din 2015, Chrome a trecut la BoringSSL, dar suportul pentru portul bazat pe NSS este menținut).
Principalele probleme pentru care vulnerabilitatea a rămas neobservată o perioadă lungă de timp:
- NSS este o bibliotecă modulară, iar testarea fuzzing s-a realizat nu în ansamblu, ci la nivel de componente individuale. De exemplu, codul de decodificare DER și procesarea certificatelor au fost verificate separat - în timpul fuzzing-ului, ar fi putut fi obținut un certificat care să conducă la manifestarea vulnerabilității discutate, dar verificarea acestuia nu ajungea la codul de verificare, iar problema nu se manifesta.
- În testarea fuzzing, s-au impus restricții stricte asupra dimensiunii ieșirii (10.000 de octeți) în absența unor limitări similare în NSS (multe structuri în mod normal puteau avea dimensiuni mai mari de 10.000 de octeți, așa că pentru identificarea problemelor era necesar un volum mai mare de date de intrare). Pentru o verificare completă, limita ar fi trebuit să fie de 224-1 octeți (16 MB), ceea ce corespunde dimensiunii maxime a certificatului admisibile în TLS.
- Reprezentare greșită a acoperirii codului prin testarea fuzzing. Codul vulnerabil a fost testat activ, dar folosind fuzzere care nu erau capabile să genereze datele de intrare necesare. De exemplu, fuzzerul tls_server_target a utilizat un set predefinit de certificate gata făcute, ceea ce a limitat verificarea codului de validare a certificatului doar la mesajele TLS și la schimbările de stare ale protocolului.
Sursa: opennet.ro
