V sadě kryptografických knihoven NSS (Network Security Services) vyvinutých Mozillou byla identifikována kritická zranitelnost (CVE-2021-43527), která může vést ke spuštění kódu útočníka při zpracování digitálních podpisů DSA nebo RSA-PSS specifikovaných pomocí Metoda kódování DER (Distinguished Encoding Rules). Problém s kódovým označením BigSig je vyřešen v NSS 3.73 a NSS ESR 3.68.1. Aktualizace balíčků v distribucích jsou dostupné pro Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Pro Fedoru zatím nejsou k dispozici žádné aktualizace.
Problém nastává v aplikacích, které používají NSS ke zpracování digitálních podpisů CMS, S/MIME, PKCS #7 a PKCS #12 nebo při ověřování certifikátů v implementacích TLS, X.509, OCSP a CRL. Tato chyba zabezpečení se může objevit v různých klientských a serverových aplikacích, které podporují TLS, DTLS a S/MIME, e-mailových klientech a prohlížečích PDF, které k ověřování digitálních podpisů používají volání NSS CERT_VerifyCertificate().
Jako příklady zranitelných aplikací jsou zmíněny LibreOffice, Evolution a Evince. Problém může také ovlivnit projekty jako Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss pro Apache http server, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Zranitelnost se však neobjevuje v prohlížečích Firefox, Thunderbird a Tor, které k ověření používají samostatnou knihovnu mozilla::pkix, která je rovněž součástí NSS. Prohlížeče založené na Chromiu (pokud nejsou speciálně vytvořeny s NSS), které do roku 2015 používaly NSS, ale poté přešly na BoringSSL, se problém také netýká.
Chyba zabezpečení je způsobena chybou v ověřovacím kódu certifikátu ve funkci vfy_CreateContext ze souboru secvfy.c. K chybě dochází, když klient čte certifikát ze serveru i když server zpracovává klientské certifikáty. Při ověřování digitálního podpisu kódovaného DER NSS dekóduje podpis do vyrovnávací paměti s pevnou velikostí a předá vyrovnávací paměť modulu PKCS #11. Při dalším zpracování se u podpisů DSA a RSA-PSS špatně kontroluje velikost, což vede k přetečení vyrovnávací paměti alokované pro strukturu VFYContextStr, pokud velikost digitálního podpisu přesáhne 16384 bitů (pro vyrovnávací paměť je alokováno 2048 bajtů, ale nekontroluje se, že podpis může být větší) ).
Kód obsahující tuto chybu zabezpečení lze vysledovat až do roku 2003, ale nepředstavoval hrozbu až do refaktoringu provedeného v roce 2012. V roce 2017 došlo ke stejné chybě při implementaci podpory RSA-PSS. K provedení útoku není k získání potřebných dat vyžadováno generování určitých klíčů náročné na zdroje, protože k přetečení dochází ve fázi před kontrolou správnosti digitálního podpisu. Část dat, která přesahuje hranice, je zapsána do paměťové oblasti obsahující ukazatele na funkce, což zjednodušuje vytváření pracovních exploitů.
Zranitelnost byla objevena výzkumníky z Google Project Zero při experimentování s novými metodami fuzzing testování a je dobrou ukázkou toho, jak mohou triviální zranitelnosti zůstat po dlouhou dobu neodhaleny v široce testovaném známém projektu:
- Kód NSS je udržován zkušeným bezpečnostním týmem pomocí nejmodernějších technik testování a analýzy chyb. Existuje několik programů, které vyplácejí významné odměny za identifikaci zranitelností v NSS.
- NSS byl jedním z prvních projektů, které se připojily k iniciativě Google oss-fuzz, a byl také testován v fuzz testovacím systému Mozilla založeném na libFuzzer.
- Knihovní kód byl mnohokrát kontrolován v různých statických analyzátorech, včetně sledování službou Coverity od roku 2008.
- Do roku 2015 se NSS používal v Google Chrome a byl nezávisle ověřen týmem Google nezávisle na Mozille (od roku 2015 Chrome přešel na BoringSSL, ale podpora portu na bázi NSS zůstává).
Hlavní problémy, kvůli kterým problém zůstal po dlouhou dobu nezjištěn:
- Modulární knihovna NSS a fuzzing testování byly prováděny nikoli jako celek, ale na úrovni jednotlivých komponent. Například kód pro dekódování DER a zpracování certifikátů byl kontrolován odděleně - při fuzzingu mohl být získán certifikát, který by vedl k projevení dotyčné zranitelnosti, ale jeho kontrola nedosáhla ověřovacího kódu a problém se nevyřešil odhalit se.
- Během testování fuzzingu byla nastavena přísná omezení na výstupní velikost (10000 10000 bajtů) při absenci podobných omezení v NSS (mnoho struktur v normálním režimu mohlo mít velikost více než 224 1 bajtů, takže k identifikaci problémů bylo zapotřebí více vstupních dat) . Pro úplné ověření měl být limit 16-XNUMX bajtů (XNUMX MB), což odpovídá maximální velikosti certifikátu povolené v TLS.
- Mylná představa o pokrytí kódu fuzz testování. Zranitelný kód byl aktivně testován, ale pomocí fuzzerů, které nebyly schopny vygenerovat potřebná vstupní data. Například fuzzer tls_server_target používal předdefinovanou sadu hotových certifikátů, která omezovala kontrolu ověřovacího kódu certifikátu pouze na zprávy TLS a změny stavu protokolu.
Zdroj: opennet.ru