En kritisk sårbarhet (CVE-2021-43527) har identifierats i NSS (Network Security Services) uppsättning kryptografiska bibliotek som utvecklats av Mozilla, vilket kan leda till exekvering av angriparkod vid bearbetning av digitala DSA- eller RSA-PSS-signaturer som specificeras med hjälp av DER-kodningsmetod ( Distinguished Encoding Rules). Problemet, med kodnamnet BigSig, är löst i NSS 3.73 och NSS ESR 3.68.1. Paketuppdateringar i distributioner är tillgängliga för Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Det finns inga tillgängliga uppdateringar för Fedora än.
Problemet uppstår i applikationer som använder NSS för att hantera CMS, S/MIME, PKCS #7 och PKCS #12 digitala signaturer, eller vid verifiering av certifikat i TLS, X.509, OCSP och CRL implementeringar. Sårbarheten kan dyka upp i olika klient- och serverapplikationer som stöder TLS, DTLS och S/MIME, e-postklienter och PDF-läsare som använder NSS CERT_VerifyCertificate()-anropet för att verifiera digitala signaturer.
LibreOffice, Evolution och Evince nämns som exempel på sårbara applikationer. Potentiellt kan problemet även påverka projekt som Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss för Apache http-servern, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Sårbarheten visas dock inte i Firefox, Thunderbird och Tor Browser, som använder ett separat mozilla::pkix-bibliotek, som också ingår i NSS, för verifiering. Krombaserade webbläsare (såvida de inte är specifikt byggda med NSS), som använde NSS fram till 2015, men sedan bytte till BoringSSL, påverkas inte heller av problemet.
Sårbarheten orsakas av ett fel i certifikatets verifieringskod i funktionen vfy_CreateContext från filen secvfy.c. Felet uppstår både när klienten läser ett certifikat från servern och när servern bearbetar klientcertifikat. När en DER-kodad digital signatur verifieras, avkodar NSS signaturen till en buffert med fast storlek och skickar bufferten till PKCS #11-modulen. Under vidare bearbetning kontrolleras storleken felaktigt för DSA- och RSA-PSS-signaturer, vilket leder till ett överflöde av bufferten som allokerats för VFYContextStr-strukturen om storleken på den digitala signaturen överstiger 16384 bitar (2048 byte tilldelas för bufferten, men det är inte kontrollerat att signaturen kan vara större) ).
Koden som innehåller sårbarheten kan spåras tillbaka till 2003, men den utgjorde inte ett hot förrän en omfaktorisering genomfördes 2012. Under 2017 gjordes samma misstag när man implementerade RSA-PSS-stöd. För att utföra en attack krävs inte resurskrävande generering av vissa nycklar för att erhålla nödvändiga data, eftersom överflödet inträffar i skedet före kontroll av den digitala signaturens korrekthet. Den del av datan som går över gränserna skrivs till ett minnesområde som innehåller pekare till funktioner, vilket förenklar skapandet av fungerande bedrifter.
Sårbarheten upptäcktes av forskare från Google Project Zero medan de experimenterade med nya otydliga testmetoder och är en bra demonstration av hur triviala sårbarheter kan förbli oupptäckta under lång tid i ett brett testat välkänt projekt:
- NSS-koden underhålls av ett erfaret säkerhetsteam som använder toppmoderna test- och felanalystekniker. Det finns flera program på plats för att betala betydande belöningar för att identifiera sårbarheter i NSS.
- NSS var ett av de första projekten som gick med i Googles oss-fuzz-initiativ och testades även i Mozillas libFuzzer-baserade fuzz-testsystem.
- Bibliotekskoden har kontrollerats många gånger i olika statiska analysatorer, bland annat har den övervakats av Coverity-tjänsten sedan 2008.
- Fram till 2015 användes NSS i Google Chrome och verifierades oberoende av Google-teamet oberoende av Mozilla (sedan 2015 bytte Chrome till BoringSSL, men stödet för den NSS-baserade porten finns kvar).
De största problemen på grund av vilka problemet förblev oupptäckt under lång tid:
- NSS modulära bibliotek och fuzzing-testning utfördes inte som en helhet, utan på nivån för enskilda komponenter. Till exempel kontrollerades koden för avkodning av DER och bearbetning av certifikat separat - under fuzzing kunde ett certifikat ha erhållits som skulle leda till manifestationen av sårbarheten i fråga, men dess kontroll nådde inte verifieringskoden och problemet nådde inte avslöja sig.
- Under fuzzing-testning sattes strikta begränsningar på utdatastorleken (10000 10000 byte) i avsaknad av liknande begränsningar i NSS (många strukturer i normalt läge kunde ha en storlek på mer än 224 1 byte, så mer indata krävdes för att identifiera problem) . För fullständig verifiering borde gränsen ha varit 16-XNUMX byte (XNUMX MB), vilket motsvarar den maximala certifikatstorleken som tillåts i TLS.
- Missuppfattning om täckning av fuzztestkod. Den sårbara koden testades aktivt, men med hjälp av fuzzers som inte kunde generera nödvändiga indata. Till exempel använde fuzzer tls_server_target en fördefinierad uppsättning färdiga certifikat, vilket begränsade kontrollen av certifikatverifieringskoden till endast TLS-meddelanden och protokolltillståndsändringar.
Källa: opennet.ru