Wiadomości o zidentyfikowanie krytycznej luki (już wymienione w CVE-2021-43527) en zestaw bibliotek kryptograficznych NSS (usługi bezpieczeństwa sieci) z Mozilli, który może doprowadzić do wykonania złośliwego kodu podczas przetwarzania podpisów cyfrowych DSA lub RSA-PSS określonych za pomocą DER (Distinguished Encoding Rules).
Problem przejawia się w aplikacjach wykorzystujących NSS do obsługi podpisów cyfrowych CMS, S/MIME, PKCS #7 i PKCS #12, lub podczas weryfikacji certyfikatów we wdrożeniach TLS, X.509, OCSP i CRL. Luka może powstać w różnych aplikacjach klienckich i serwerowych z obsługą TLS, DTLS i S/MIME, klientach poczty e-mail i przeglądarkach plików PDF, które wykorzystują wywołanie NSS CERT_VerifyCertificate() do weryfikacji podpisów cyfrowych.
LibreOffice, Evolution i Evince są wymieniane jako przykłady podatnych aplikacji. Potencjalnie problem może dotyczyć również projektów takich jak między innymi Pidgin, Apache OpenOffice, Suricata, Curl.
W tym samym czasie luka nie pojawia się w Firefox, Thunderbird i Tor Browser, które do weryfikacji używają oddzielnej biblioteki mozilla :: pkix, która również jest częścią NSS. ten Przeglądarki oparte na Chrome (chyba że zostały specjalnie skompilowane z NSS), który używał NSS do 2015 roku, ale potem został przeniesiony do BoringSSL, problem nie dotyczy ich.
Luka wynika z błędu w kodzie weryfikacji certyfikatu w vfy_CreateContext funkcja pliku secvfy.c. Błąd objawia się zarówno wtedy, gdy klient odczytuje certyfikat z serwera tak jak wtedy, gdy serwer przetwarza certyfikaty klienta.
Podczas weryfikacji podpisu cyfrowego zakodowanego w formacie DER, NSS dekoduje podpis do bufora o stałym rozmiarze i przekazuje ten bufor do modułu PKCS nr 11. Podczas przetwarzania końcowego dla podpisów DSA i RSA-PSS rozmiar jest błędnie weryfikowany, co skutkuje w którym prowadzi do przepełnienia przydzielonego bufora dla struktury VFYContextStr, jeśli rozmiar podpisu cyfrowego przekracza 16384 bity (2048 bajtów jest przydzielonych na bufor, ale nie jest weryfikowane, czy podpis może być większy).
Kod zawierający lukę pochodzi z 2003 roku, ale nie było to zagrożenie aż do refaktoryzacji w 2012 roku. W 2017 roku ten sam błąd popełniono przy wdrażaniu obsługi RSA-PSS. Do przeprowadzenia ataku nie jest wymagane zasobochłonne generowanie pewnych kluczy w celu uzyskania niezbędnych danych, ponieważ przepełnienie następuje na etapie poprzedzającym weryfikację ważności podpisu cyfrowego. Część danych spoza zakresu jest zapisywana w obszarze pamięci zawierającym wskaźniki do funkcji, co ułatwia tworzenie działających exploitów.
Luka została zidentyfikowana przez badaczy Google Project Zero podczas eksperymentów z nowymi metodami testowania fuzzingu i jest dobrą demonstracją tego, jak trywialne podatności mogą pozostać niewykryte przez długi czas w dobrze przetestowanym znanym projekcie.
Jeśli chodzi o główne problemy, dla których problem pozostał niezauważony przez długi czas:
- Biblioteka napędów NSS i testy fuzzingu nie zostały przeprowadzone w całości, ale na poziomie poszczególnych komponentów.
- Na przykład kod do dekodowania DER i przetwarzania certyfikatów był weryfikowany osobno; W trakcie fuzzingu równie dobrze można było uzyskać certyfikat prowadzący do ujawnienia omawianej podatności, ale jego weryfikacja nie dotarła do kodu weryfikacyjnego i problem nie został ujawniony.
- Podczas testów fuzzingu ustalono ścisłe limity wielkości wyjścia (10,000 10,000 bajtów) w przypadku braku takich ograniczeń w NSS (wiele struktur w trybie normalnym może być większych niż 2 24 bajtów, dlatego do zidentyfikowania problemów potrzeba więcej danych wejściowych ). Dla pełnej weryfikacji limit powinien wynosić 1 16 -XNUMX bajtów (XNUMX MB), co odpowiada maksymalnemu rozmiarowi certyfikatu dozwolonemu w TLS.
- Błędne przekonanie o pokryciu kodu przez testy fuzzingowe. Podatny kod był aktywnie testowany, ale przy użyciu fuzerów, które nie były w stanie wygenerować wymaganych danych wejściowych. Na przykład fuzzer tls_server_target użył wstępnie zdefiniowanego zestawu gotowych certyfikatów, co ogranicza weryfikację kodu weryfikacyjnego certyfikatu tylko do komunikatów TLS i zmian stanu protokołu.
Wreszcie, Warto wspomnieć, że problem z kryptonimem BigSig został naprawiony w NSS 3.73 i NSS ESR 3.68.1 a aktualizacje rozwiązania w postaci pakietów zostały już wydane w różnych dystrybucjach: Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD itp.
Jeśli chcesz dowiedzieć się więcej na ten temat, możesz skonsultować się poniższy link.