V sadě kryptografických knihoven NSS (Network Security Services) vyvíjených společností Mozilla byla odhalena kritická zranitelnost (CVE-2021-43527), která může vést k vykonání kódu útočníka při zpracování digitálních podpisů DSA nebo RSA-PSS zadaných pomocí kódování DER (Distinguished Encoding Rules). Problém, kterému bylo přiděleno kódové jméno BigSig, byl odstraněn ve verzích NSS 3.73 a NSS ESR 3.68.1. Aktualizace balíčků jsou k dispozici pro distribuce Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Pro Fedora zatím nejsou dostupné žádné aktualizace.
Problém se projevuje v aplikacích, které používají NSS pro 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. Zranitelnost se může objevit v různých klientských a serverových aplikacích s podporou TLS, DTLS a S/MIME, e-mailových klientech a PDF prohlížečích, které používají výzvu NSS CERT_VerifyCertificate() k ověřování digitálních podpisů.
Mezi příklady ohrožených aplikací patří LibreOffice, Evolution a Evince. Potenciálně by problém mohl zahrnovat také projekty jako Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss pro http server Apache, Oracle Communications Messaging Server a Oracle Directory Server Enterprise Edition. Na druhou stranu zranitelnost nepostihuje Firefox, Thunderbird a Tor Browser, které používají jinou knihovnu pro ověřování mozilla::pkix, která je také součástí NSS. Problém se také netýká prohlížečů založených na Chromiu (pokud nebyly speciálně zkompilovány s NSS), které používaly NSS do roku 2015, ale poté přešly na BoringSSL.
Zranitelnost je způsobena chybou v kódu ověřování certifikátů v funkci vfy_CreateContext z souboru secvfy.c. Problém se projevuje jak při čtení certifikátu klienta ze serveru, tak při zpracování serverem certifikátů klientů. Při ověřování digitálního podpisu zakódovaného metodou DER NSS dekóduje podpis do pevně stanoveného bufferu a předává tento buffer modulu PKCS #11. Při dalším zpracování, pro podpisy DSA a RSA-PSS, není správně kontrolována velikost, což vede k přetečení bufferu vyhrazeného pro strukturu VFYContextStr, pokud je velikost digitálního podpisu větší než 16384 bitů (buffer je vyhrazen na 2048 bajtů, ale není kontrolováno, že podpis může být větší).
Kód obsahující zranitelnost se sleduje od roku 2003, ale nepředstavoval hrozbu až do refaktoringu provedeného v roce 2012. V roce 2017, při implementaci podpory RSA-PSS, byla udělána stejná chyba. Pro provedení útoku není třeba výpočetně náročná generace určitých klíčů k získání potřebných dat, protože přetečení nastává ve fázi před kontrolou správnosti digitálního podpisu. Část dat vyčnívající za hranice se zapisuje do oblasti paměti obsahující ukazatele na funkce, což usnadňuje vytváření funkčních exploitů.
Zranitelnost byla odhalena výzkumníky z Google Project Zero během experimentů s novými metodami fuzzingového testování a je dobrým příkladem toho, jak mohou triviality zůstat po dlouhou dobu nepovšimnuté v široce testovaných známých projektech:
- Kód NSS je doprovázen zkušeným týmem zodpovědným za bezpečnost, který používá moderní metody testování a analýzy chyb. Existuje několik programů na vyplácení významných odměn za odhalení 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 rozvíjeném systému fuzzingového testování Mozilly založeném na libFuzzer.
- Kód knihovny byl opakovaně kontrolován v různých statických analytických nástrojích, včetně sledování službou Coverity od roku 2008.
- Do roku 2015 se NSS používal v Google Chrome a nezávisle na Mozille byl kontrolován týmem Google (od roku 2015 přešel Chrome na BoringSSL, ale podpora portu založeného na NSS zůstává).
Hlavní problémy, kvůli nimž zůstával problém dlouho neodhalený:
- NSS je modulární knihovna a fuzzingové testování se neprovádělo komplexně, ale na úrovni jednotlivých komponent. Například byl zvlášť kontrolován kód pro dekódování DER a zpracování certifikátů — během fuzzingového procesu bylo možné získat certifikát, který vedl k projevování zmiňované zranitelnosti, ale jeho kontrola nedosáhla kódu pro verifikaci a problém se neodhalil.
- Při fuzzingovém testování byla stanovena přísná omezení na velikost výstupu (10000 bytů), zatímco v NSS taková omezení neexistovala (mnoho struktur v běžném režimu mohlo mít velikost větší než 10000 bytů, proto bylo k odhalení problémů potřeba větší objem vstupních dat). Pro plnohodnotné ověření by limit měl být 224-1 byt (16 MB), což odpovídá maximální velikosti certifikátu povoleného v TLS.
- Nesprávné zobrazení pokrytí kódu fuzzingovým testováním. Zranitelný kód byl aktivně testován, ale s použitím fuzzery, které nebyly schopny vygenerovat potřebné vstupní údaje. Například fuzzer tls_server_target používal předdefinovaný soubor připravených certifikátů, což omezovalo kontrolu kódu ověření certifikátu pouze na TLS zprávy a změny stavu protokolu.
Zdroj: opennet.ru
