Nyheten om identifiera en kritisk sårbarhet (redan listad under CVE-2021-43527) en uppsättningen av kryptografiska bibliotek NSS (Nätverkssäkerhetstjänster) från Mozilla som kan leda till exekvering av skadlig kod vid behandling av digitala DSA- eller RSA-PSS-signaturer specificerade med DER (Distinguished Encoding Rules).
Problemet yttrar sig i applikationer som använder NSS för att hantera digitala signaturer CMS, S / MIME, PKCS # 7 och PKCS # 12, eller när du verifierar certifikat i distributioner TLS, X.509, OCSP och CRL. Sårbarheten kan uppstå i olika klient- och serverapplikationer med stöd för 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, bland andra.
Samtidigt, sårbarheten visas inte i Firefox, Thunderbird och Tor Browser, som använder ett separat mozilla :: pkix-bibliotek för verifiering, som också är en del av NSS. De Chrome-baserade webbläsare (såvida de inte kompilerades specifikt med NSS), som använde NSS fram till 2015, men sedan överfördes till BoringSSL, de berörs inte av problemet.
Sårbarheten beror på en bugg i certifikatets verifieringskod i vfy_CreateContext funktion för filen secvfy.c. Felet visar sig både när klienten läser certifikatet från servern som när servern bearbetar klientens certifikat.
När en DER-kodad digital signatur verifieras, avkodar NSS signaturen till en buffert med fast storlek och skickar denna buffert till modulen PKCS # 11. Under efterbearbetning, för DSA- och RSA-PSS-signaturer, verifieras storleken felaktigt, vilket resulterar i i vilket leder till ett spill av den allokerade bufferten för VFYContextStr-strukturen, om storleken på den digitala signaturen överstiger 16384 bitar (2048 byte tilldelas för bufferten, men det är inte verifierat att signaturen kan vara större).
Koden som innehåller sårbarheten går tillbaka till 2003, men det var inte ett hot förrän omfaktorn 2012. Under 2017 gjordes samma misstag när man implementerade RSA-PSS-stöd. För att utföra en attack krävs inte en resurskrävande generering av vissa nycklar för att erhålla nödvändiga data, eftersom överflödet sker i skedet före verifieringen av den digitala signaturens giltighet. Den out-of-bounds-delen av data skrivs till ett minnesområde som innehåller funktionspekare, vilket gör det enkelt att skapa fungerande exploateringar.
Sårbarheten identifierades av Google Project Zero-forskare under experiment med nya fuzzing testmetoder och är en bra demonstration av hur triviala sårbarheter kan förbli oupptäckta under lång tid i ett väl beprövat känt projekt.
Som för huvudproblem för vilka problemet gick obemärkt förbi under en lång tid:
- NSS-enhetsbiblioteket och fuzzing-testerna utfördes inte i sin helhet, utan på individuell komponentnivå.
- Till exempel verifierades koden för att avkoda DER och processcertifikat separat; Under loppet av fuzzingen kunde ett certifikat mycket väl ha erhållits, vilket ledde till manifestationen av sårbarheten i fråga, men dess verifiering nådde inte verifieringskoden och problemet avslöjades inte.
- Under fuzzing-testerna sattes strikta gränser för storleken på utdata (10,000 10,000 byte) i avsaknad av sådana begränsningar i NSS (många strukturer i normalt läge kan vara större än 2 24 byte, därför krävs det mer indata för att identifiera problem för att identifiera problem ). För fullständig verifiering borde gränsen ha varit 1 16 -XNUMX byte (XNUMX MB), vilket motsvarar den maximala storleken på ett certifikat som tillåts i TLS.
- Missuppfattning om kodtäckning genom fuzzing tester. Den sårbara koden testades aktivt, men med hjälp av fuzers, som inte kunde generera nödvändiga indata. Till exempel använde fuzzer tls_server_target en fördefinierad uppsättning av färdiga certifikat, vilket begränsade verifieringen av certifikatverifieringskoden till endast TLS-meddelanden och protokolltillståndsändringar.
Slutligen, Det är värt att nämna att problemet med kodnamnet BigSig har åtgärdats i NSS 3.73 och NSS ESR 3.68.1 och uppdateringarna av lösningen i paketform har redan släppts i de olika distributionerna: Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD, etc.
Om du vill veta mer om det kan du rådfråga följande länk.