Er is een kritieke kwetsbaarheid (CVE-2021-43527) geïdentificeerd in de NSS-set (Network Security Services) van cryptografische bibliotheken ontwikkeld door Mozilla, die kan leiden tot de uitvoering van aanvallercode bij het verwerken van digitale DSA- of RSA-PSS-handtekeningen die zijn gespecificeerd met behulp van de DER-coderingsmethode (Distinguished Encoding Rules). Het probleem, met de codenaam BigSig, is opgelost in NSS 3.73 en NSS ESR 3.68.1. Pakketupdates in distributies zijn beschikbaar voor Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Er zijn nog geen updates beschikbaar voor Fedora.
Het probleem doet zich voor in toepassingen die NSS gebruiken voor het verwerken van digitale handtekeningen van CMS, S/MIME, PKCS #7 en PKCS #12, of bij het verifiëren van certificaten in TLS-, X.509-, OCSP- en CRL-implementaties. Het beveiligingslek kan voorkomen in verschillende client- en servertoepassingen die TLS, DTLS en S/MIME ondersteunen, e-mailclients en PDF-viewers die de NSS CERT_VerifyCertificate()-aanroep gebruiken om digitale handtekeningen te verifiëren.
LibreOffice, Evolution en Evince worden genoemd als voorbeelden van kwetsbare applicaties. Mogelijk kan het probleem ook van invloed zijn op projecten zoals Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss voor de Apache http-server, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. De kwetsbaarheid komt echter niet voor in Firefox, Thunderbird en Tor Browser, die ter verificatie een aparte mozilla::pkix-bibliotheek gebruiken, ook opgenomen in NSS. Chromium-gebaseerde browsers (tenzij ze specifiek met NSS zijn gebouwd), die tot 2015 NSS gebruikten, maar daarna overstapten op BoringSSL, hebben ook geen last van het probleem.
Het beveiligingslek wordt veroorzaakt door een fout in de certificaatverificatiecode in de vfy_CreateContext-functie van het secvfy.c-bestand. De fout treedt zowel op wanneer de client een certificaat van de server leest als wanneer de server clientcertificaten verwerkt. Bij het verifiëren van een DER-gecodeerde digitale handtekening decodeert NSS de handtekening in een buffer met een vaste grootte en geeft de buffer door aan de PKCS #11-module. Tijdens verdere verwerking wordt de grootte onjuist gecontroleerd op DSA- en RSA-PSS-handtekeningen, wat leidt tot een overloop van de buffer die is toegewezen aan de VFYContextStr-structuur als de grootte van de digitale handtekening groter is dan 16384 bits (2048 bytes worden toegewezen aan de buffer, maar er wordt niet gecontroleerd of de handtekening groter kan zijn)).
De code met de kwetsbaarheid is terug te voeren tot 2003, maar vormde pas een bedreiging toen er in 2012 een refactoring werd uitgevoerd. In 2017 werd dezelfde fout gemaakt bij de implementatie van RSA-PSS-ondersteuning. Om een aanval uit te voeren is het genereren van bepaalde sleutels niet nodig om de benodigde gegevens te verkrijgen, omdat de overloop plaatsvindt in de fase vóór het controleren van de juistheid van de digitale handtekening. Het deel van de gegevens dat de grenzen overschrijdt, wordt naar een geheugengebied geschreven dat verwijzingen naar functies bevat, wat het creëren van werkende exploits vereenvoudigt.
De kwetsbaarheid werd ontdekt door onderzoekers van Google Project Zero tijdens het experimenteren met nieuwe fuzzing-testmethoden en is een goede demonstratie van hoe triviale kwetsbaarheden lange tijd onopgemerkt kunnen blijven in een algemeen getest, bekend project:
- De NSS-code wordt onderhouden door een ervaren beveiligingsteam met behulp van de modernste test- en foutanalysetechnieken. Er bestaan verschillende programma's die aanzienlijke beloningen uitkeren voor het identificeren van kwetsbaarheden in NSS.
- NSS was een van de eerste projecten die zich aansloot bij het oss-fuzz-initiatief van Google en werd ook getest in Mozilla's op libFuzzer gebaseerde fuzz-testsysteem.
- De bibliotheekcode is vele malen gecontroleerd in verschillende statische analysers, waaronder sinds 2008 door de Coverity-service.
- Tot 2015 werd NSS gebruikt in Google Chrome en onafhankelijk geverifieerd door het Google-team, onafhankelijk van Mozilla (sinds 2015 schakelde Chrome over op BoringSSL, maar ondersteuning voor de op NSS gebaseerde poort blijft bestaan).
De belangrijkste problemen waardoor het probleem lange tijd onopgemerkt bleef:
- De modulaire NSS-bibliotheek en fuzzing-tests werden niet als geheel uitgevoerd, maar op het niveau van individuele componenten. De code voor het decoderen van DER en het verwerken van certificaten werd bijvoorbeeld afzonderlijk gecontroleerd - tijdens het fuzzen had een certificaat kunnen worden verkregen dat zou leiden tot de manifestatie van de betreffende kwetsbaarheid, maar de controle bereikte de verificatiecode niet en het probleem deed zich niet voor zichzelf openbaren.
- Tijdens fuzzing-tests werden strikte beperkingen ingesteld op de uitvoergrootte (10000 bytes) bij gebrek aan soortgelijke beperkingen in NSS (veel structuren in de normale modus konden een grootte hebben van meer dan 10000 bytes, dus er waren meer invoergegevens nodig om problemen te identificeren) . Voor volledige verificatie had de limiet 224-1 bytes (16 MB) moeten zijn, wat overeenkomt met de maximale certificaatgrootte die is toegestaan in TLS.
- Misvatting over de dekking van fuzz-testcodes. De kwetsbare code werd actief getest, maar met behulp van fuzzers die niet in staat waren de benodigde invoergegevens te genereren. Fuzzer tls_server_target gebruikte bijvoorbeeld een vooraf gedefinieerde set kant-en-klare certificaten, waardoor de controle van de certificaatverificatiecode werd beperkt tot alleen TLS-berichten en protocolstatuswijzigingen.
Bron: opennet.ru