Der er opdaget en kritisk sårbarhed (CVE-2021-43527) i kryptografibibliotekerne NSS (Network Security Services), udviklet af Mozilla, som kan føre til udførelse af ondsindet kode ved behandling af digitale DSA- eller RSA-PSS-underskrifter, der er angivet ved hjælp af DER (Distinguished Encoding Rules) kodningsmetoden. Problemet, der er givet kodenavnet BigSig, er blevet rettet i versionerne NSS 3.73 og NSS ESR 3.68.1. Opdateringer til pakker i distributionerne er tilgængelige for Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Opdateringer til Fedora er endnu ikke tilgængelige.
Problemet opstår i applikationer, der bruger NSS til at behandle digitale CMS-, S/MIME-, PKCS #7- og PKCS #12-underskrifter, eller ved validering af certifikater i implementeringer af TLS, X.509, OCSP og CRL. Sårbarheden kan dukke op i forskellige klient- og serverapplikationer med understøttelse af TLS, DTLS og S/MIME, e-mailklienter og PDF-læsere, der bruger NSS-funktionen CERT_VerifyCertificate() til at kontrollere digitale underskrifter.
Eksempler på sårbare applikationer inkluderer LibreOffice, Evolution og Evince. Problemet kan også potentielt påvirke projekter som Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss til Apache HTTP-serveren, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Sårbarheden optræder ikke i Firefox, Thunderbird og Tor Browser, hvor der anvendes et separat bibliotek mozilla::pkix til validering, som også er en del af NSS. Browsere baseret på Chromium er heller ikke udsat (medmindre de er specifikt bygget med NSS), da de brugte NSS frem til 2015, men derefter blev overført til BoringSSL.
Sårbarheden skyldes en fejl i koden til validering af certifikater i funktionen vfy_CreateContext fra filen secvfy.c. Fejlen opstår både ved læsning af klientens certifikat fra serveren samt ved behandling serveren af klienters certifikater. Under valideringen af en digital underskrift, der er kodet med DER-metoden, dekoder NSS underskriften til en buffer med fast størrelse og sender denne buffer til PKCS #11-modulet. Ved videre behandling bliver størrelsen for DSA- og RSA-PSS-underskrifter ikke korrekt kontrolleret, hvilket fører til buffer-overløb for den tildelte struktur VFYContextStr, hvis størrelsen på den digitale underskrift overstiger 16384 bits (2048 bytes er tildelt til bufferen, men det kontrolleres ikke, at underskriften kan være større).
Kode med sårbarhed kan spores tilbage til 2003, men det udgjorde ikke en trussel før refaktoreringen i 2012. I 2017 blev den samme fejl begået ved implementeringen af støtte til RSA-PSS. For at udføre et angreb kræves der ikke ressourcekrævende generering af bestemte nøgler for at få de nødvendige data, da bufferoverløbet sker i fasen før kontrol af digitale signaturer. Data, der overskrider grænserne, skrives ind i et hukommelsesområde, der indeholder funktionspegere, hvilket letter oprettelsen af fungerende exploits.
Sårbarheden blev opdaget af forskere fra Google Project Zero under eksperimenter med nye metoder til fuzzing-testning og er et godt eksempel på, hvordan trivielle sårbarheder kan forblive uopdagede i et velafprøvet, kendt projekt i lang tid:
- NSS-kode er ledsaget af et erfarent team, der har ansvaret for sikkerhed, som anvender moderne metoder til testning og fejlanalyse. Der er flere programmer med betydelige belønninger for at finde sårbarheder i NSS.
- NSS var et af de første projekter, der tilsluttede sig Google OSS-fuzz-initiativer og blev også testet i Mozillas udviklede fuzzing-testningssystem baseret på libFuzzer.
- Koden i biblioteket er blevet kontrolleret gentagne gange af forskellige statiske analyseværktøjer, herunder siden 2008, hvor den er blevet overvåget af Coverity.
- Indtil 2015 blev NSS brugt i Google Chrome og blev uafhængigt kontrolleret af Google-teamet (siden 2015 er Chrome skiftet til BoringSSL, men understøttelsen af porten baseret på NSS opretholdes).
De væsentligste problemer, som gjorde, at sårbarheden forblev uopdaget i lang tid:
- NSS er et modulær bibliotek, og fuzzing-testningen blev ikke udført samlet, men på niveauet for individuelle komponenter. For eksempel blev koden til dekodning af DER og behandling af certifikater testet separat — under fuzzing kunne et certifikat, der førte til den betroede sårbarhed, være opnået, men dets verificering nåede ikke til koden for verifikation, og problemet blev ikke afdækket.
- Under fuzzing testing, strict output size limits were set (10,000 bytes) while no such restrictions existed in NSS (many structures in normal mode could exceed 10,000 bytes, so a larger volume of input data was needed to identify issues). For a complete check, the limit should have been 224-1 bytes (16 MB), which corresponds to the maximum certificate size allowed in TLS.
- There was a misunderstanding regarding the coverage of code through fuzzing testing. Vulnerable code was actively tested, but using fuzzers that were unable to generate the required input data. For example, the fuzzer tls_server_target utilized a predefined set of ready-made certificates, which limited the verification code testing to only TLS messages and changes in protocol state.
Kilde: opennet.ru
