O vulnerabilitate critică (CVE-2021-43527) a fost identificată în setul de biblioteci criptografice NSS (Network Security Services) dezvoltat de Mozilla, care poate duce la executarea codului atacatorului la procesarea semnăturilor digitale DSA sau RSA-PSS specificate folosind Metoda de codificare DER (Distinguished Encoding Rules). Problema, cu numele de cod BigSig, este rezolvată în NSS 3.73 și NSS ESR 3.68.1. Actualizările pachetelor din distribuții sunt disponibile pentru Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Nu există încă actualizări disponibile pentru Fedora.
Problema apare în aplicațiile care utilizează NSS pentru a gestiona semnăturile digitale CMS, S/MIME, PKCS #7 și PKCS #12 sau când se verifică certificatele în implementările TLS, X.509, OCSP și CRL. Vulnerabilitatea poate apărea în diverse aplicații client și server care acceptă TLS, DTLS și S/MIME, clienți de e-mail și vizualizatoare PDF care utilizează apelul NSS CERT_VerifyCertificate() pentru a verifica semnăturile digitale.
LibreOffice, Evolution și Evince sunt menționate ca exemple de aplicații vulnerabile. 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 Apache http, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Cu toate acestea, vulnerabilitatea nu apare în Firefox, Thunderbird și Tor Browser, care utilizează o bibliotecă separată mozilla::pkix, inclusă și în NSS, pentru verificare. Browserele bazate pe Chromium (cu excepția cazului în care sunt construite special cu NSS), care au folosit NSS până în 2015, dar apoi au trecut la BoringSSL, nu sunt nici ele afectate de problemă.
Vulnerabilitatea este cauzată de o eroare în codul de verificare a certificatului din funcția vfy_CreateContext din fișierul secvfy.c. Eroarea apare atât atunci când clientul citește un certificat de pe server, cât și atunci când serverul procesează certificate client. Când verifică o semnătură digitală codificată DER, NSS decodifică semnătura într-un buffer de dimensiune fixă și transmite tamponul către modulul PKCS #11. În timpul procesării ulterioare, dimensiunea este verificată incorect pentru semnăturile DSA și RSA-PSS, ceea ce duce la o depășire a buffer-ului alocat pentru structura VFYContextStr dacă dimensiunea semnăturii digitale depășește 16384 de biți (2048 de octeți sunt alocați pentru buffer, dar nu se verifica ca semnatura sa fie mai mare) ).
Codul care conține vulnerabilitatea poate fi urmărit încă din 2003, dar nu a reprezentat o amenințare până la o refactorizare efectuată în 2012. În 2017, aceeași greșeală a fost făcută la implementarea suportului RSA-PSS. Pentru a efectua un atac, generarea anumitor chei cu resurse intensive nu este necesară pentru a obține datele necesare, deoarece depășirea are loc în etapa înainte de verificarea corectitudinii semnăturii digitale. Partea de date care depășește limitele este scrisă într-o zonă de memorie care conține pointeri către funcții, ceea ce simplifică crearea de exploit-uri de lucru.
Vulnerabilitatea a fost descoperită de cercetătorii de la Google Project Zero în timp ce experimentau noi metode de testare fuzzing și este o bună demonstrație a modului în care vulnerabilitățile banale pot rămâne nedetectate mult timp într-un proiect bine-cunoscut testat pe scară largă:
- Codul NSS este întreținut de o echipă de securitate cu experiență, folosind tehnici de testare și analiză a erorilor de ultimă generație. Există mai multe programe în vigoare pentru a plăti recompense semnificative pentru identificarea vulnerabilităților în NSS.
- NSS a fost unul dintre primele proiecte care s-a alăturat inițiativei oss-fuzz a Google și a fost, de asemenea, testat în sistemul de testare fuzz bazat pe libFuzzer al Mozilla.
- Codul bibliotecii a fost verificat de multe ori în diverse analizoare statice, inclusiv fiind monitorizat de serviciul Coverity din 2008.
- Până în 2015, NSS a fost folosit în Google Chrome și a fost verificat independent de echipa Google, independent de Mozilla (din 2015, Chrome a trecut la BoringSSL, dar suportul pentru portul bazat pe NSS rămâne).
Principalele probleme din cauza cărora problema a rămas nedetectată mult timp:
- Biblioteca modulară NSS și testarea fuzzing au fost efectuate nu ca un întreg, ci la nivelul componentelor individuale. De exemplu, codul pentru decodarea DER și procesarea certificatelor a fost verificat separat - în timpul fuzzing-ului, s-ar fi putut obține un certificat care să ducă la manifestarea vulnerabilității în cauză, dar verificarea acestuia nu a ajuns la codul de verificare și problema nu a ajuns. se dezvăluie.
- În timpul testării fuzzing, au fost stabilite restricții stricte asupra mărimii de ieșire (10000 de octeți) în absența unor restricții similare în NSS (multe structuri în modul normal ar putea avea o dimensiune mai mare de 10000 de octeți, deci au fost necesare mai multe date de intrare pentru a identifica problemele) . Pentru verificarea completă, limita ar fi trebuit să fie de 224-1 octeți (16 MB), ceea ce corespunde dimensiunii maxime a certificatului permisă în TLS.
- Concepție greșită despre acoperirea codului de testare fuzz. Codul vulnerabil a fost testat activ, dar folosind fuzzere care nu au putut genera datele de intrare necesare. De exemplu, fuzzer tls_server_target a folosit un set predefinit de certificate gata făcute, care a limitat verificarea codului de verificare a certificatului la numai mesajele TLS și modificările stării protocolului.
Sursa: opennet.ru