In de set cryptografische bibliotheken NSS (Network Security Services), ontwikkeld door Mozilla, is een kritieke kwetsbaarheid (CVE-2021-43527) ontdekt die kan leiden tot de uitvoering van code door een aanvaller bij de verwerking van digitale handtekeningen DSA of RSA-PSS, opgegeven met behulp van de DER-codering (Distinguished Encoding Rules) methode. Het probleem, codenaam BigSig, is verholpen in de releases NSS 3.73 en NSS ESR 3.68.1. Pakketupdates zijn beschikbaar voor distributies zoals Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo en FreeBSD. Updates voor Fedora zijn nog niet beschikbaar.
Het probleem manifesteert zich in applicaties die NSS gebruiken voor de verwerking van digitale handtekeningen CMS, S/MIME, PKCS #7 en PKCS #12, of bij de verificatie van certificaten in implementaties van TLS, X.509, OCSP en CRL. De kwetsbaarheid kan zich voordoen in verschillende client- en serverapplicaties die TLS, DTLS en S/MIME ondersteunen, in e-mailclients en PDF-lezers die de NSS-aanroep CERT_VerifyCertificate() gebruiken voor de verificatie van digitale handtekeningen.
Voorbeelden van kwetsbare applicaties zijn onder andere LibreOffice, Evolution en Evince. Potentieel kan het probleem ook projecten zoals Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss voor de http-server Apache, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition treffen. De kwetsbaarheid is echter niet aanwezig in Firefox, Thunderbird en Tor Browser, die een aparte bibliotheek mozilla::pkix gebruiken voor verificatie, die ook deel uitmaakt van NSS. Browsers op basis van Chromium zijn ook niet kwetsbaar (tenzij ze speciaal met NSS zijn gebouwd) en hebben NSS tot 2015 gebruikt, maar zijn toen overgestapt op BoringSSL.
De kwetsbaarheid wordt veroorzaakt door een fout in de code voor de verificatie van certificaten in de functie vfy_CreateContext uit het bestand secvfy.c. De fout doet zich voor zowel bij het lezen van een clientcertificaat van de server als bij de verwerking server van clientcertificaten. Tijdens de controle van een digitale handtekening die is gecodeerd met de DER-methode, decodeert NSS de handtekening in een buffer met een vaste grootte en geeft deze buffer door aan de PKCS #11-module. Bij verdere verwerking worden de afmetingen voor DSA- en RSA-PSS-handtekeningen niet correct gecontroleerd, wat leidt tot een buffer overflow van de structurale VFYContextStr, als de digitale handtekening groter is dan 16384 bits (er wordt een buffer van 2048 bytes gereserveerd, maar er wordt niet gecontroleerd of de handtekening groter kan zijn).
De kwetsbare code is te traceren tot 2003, maar vormde geen bedreiging tot de herstructurering in 2012. In 2017 werd dezelfde fout gemaakt bij de implementatie van RSA-PSS-ondersteuning. Voor een aanval zijn geen resource-intensieve generaties van specifieke sleutels nodig om de gewenste gegevens te verkrijgen, aangezien de buffer-overloop plaatsvindt vĆ³Ć³r de controle van de geldigheid van de digitale handtekening. De buiten de grenzen vallende gegevens worden geschreven in een geheugenruimte die aanwijzers naar functies bevat, wat het creĆ«ren van werkende exploits vergemakkelijkt.
De kwetsbaarheid werd ontdekt door onderzoekers van Google Project Zero tijdens experimenten met nieuwe methoden voor fuzzing-testen en is een goede demonstratie van hoe triviale kwetsbaarheden lange tijd onopgemerkt kunnen blijven in een goed getest en bekend project:
- De NSS-code wordt vergezeld door een ervaren team dat verantwoordelijk is voor de beveiliging en moderne methoden voor testen en foutanalyse toepast. Er zijn verschillende programma's voor het uitkeren van substantiƫle beloningen voor het ontdekken van kwetsbaarheden in NSS.
- NSS was een van de eerste projecten die zich aansloten bij het Google oss-fuzz-initiatief en werd ook getest in het ontwikkelde fuzzing-testingssysteem van Mozilla op basis van libFuzzer.
- De code van de bibliotheek is meerdere keren gecontroleerd door verschillende statische analysetools, waaronder de service Coverity die sinds 2008 in de gaten wordt gehouden.
- Tot 2015 werd NSS gebruikt in Google Chrome en werd onafhankelijk van Mozilla gecontroleerd door het Google-team (vanaf 2015 is Chrome overgeschakeld op BoringSSL, maar de ondersteuning voor de NSS-gebaseerde port blijft bestaan).
De belangrijkste problemen waardoor het probleem lange tijd onopgemerkt bleef:
- NSS is een modulaire bibliotheek en het fuzzing-testen werd niet als geheel uitgevoerd, maar op het niveau van afzonderlijke componenten. Bijvoorbeeld, de DECODER-code en de verwerking van certificaten werden afzonderlijk getest ā tijdens de fuzzing kon er een certificaat worden verkregen dat de besproken kwetsbaarheid blootlegde, maar de controle ervan bereikte de verificatiecode niet, waardoor het probleem onopgemerkt bleef.
- Bij fuzzing-testen werden strikte beperkingen gesteld aan de uitvoerwaarde (10000 bytes), terwijl dergelijke beperkingen in NSS ontbraken (veel structuren konden in de normale modus groter zijn dan 10000 bytes, daarom was een grotere hoeveelheid invoergegevens nodig om problemen te identificeren). Voor een complete validatie moest de limiet 224-1 bytes (16 MB) zijn, wat overeenkomt met de maximale grootte van een certificaat die is toegestaan in TLS.
- Onjuiste representatie van de dekking van de code door fuzzing-testen. Kwetsbare code werd actief getest, maar met gebruik van fuzzers die niet in staat waren om de benodigde invoergegevens te genereren. Bijvoorbeeld, de fuzzer tls_server_target gebruikte een vooraf gedefinieerde set van kant-en-klare certificaten, waardoor de controle van de certificaatverificatieworking beperkt bleef tot TLS-berichten en protocollestatemutaties.
Bron: opennet.ru
