CVE-2023-33201

W Bouncy Castle for Java przed 1.86 (oraz LTS przed 2.73.13) rodziny PBES1 i PKCS#12 PBE używały liczby iteracji pochodzącej z niezaufanych danych wejściowych bez ograniczenia, co pozwalało na wymuszenie dowolnie dużego nakładu pracy. Poprawka odrzuca ujemną lub przekraczającą limit liczbę iteracji (domyślnie 10 000 000) na podstawie właściwości org.bouncycastle.pbe.max_iteration_count.

W Bouncy Castle for Java przed wersją 1.86 walidacja listy propozycji w zewnętrznym commicie MLS (RFC 9420) nie sprawdzała, czy usuwany liść faktycznie należy do dołączającego. Brak tej weryfikacji pozwalał każdej osobie posiadającej publiczne GroupInfo grupy na wysłanie commitu z propozycją Remove wskazującą dowolnego członka, co skutkowało jego usunięciem i przejęciem jego miejsca w drzewie ratchet. Poprawka wymusza zgodność poświadczenia usuwanego liścia z poświadczeniem nowego liścia dołączającego po obu stronach.

W Bouncy Castle for Java przed wersją 1.86 parser strumieniowy CMS AuthenticatedData akceptował komunikaty, w których pola digestAlgorithm i authAttrs były niespójne co do obecności uwierzytelnionych atrybutów. Parser podejmował decyzję na podstawie samego digestAlgorithm, przez co mógł zweryfikować MAC treści i zwrócić atrybuty przez getAuthAttrs() jako uwierzytelnione, mimo że MAC nigdy ich nie obejmował. Problem dotyczy również wersji LTS przed 2.73.13 oraz wydań FIPS (BC-FJA) przed odpowiednimi wersjami bcpkix-fips i bcutil-fips.

W Bouncy Castle for Java przed wersją 1.86 wysokopoziomowe API OpenPGP akceptowało podpis danych wykonany przez podklucz podpisujący, którego sygnatura wiążąca podklucz nie zawierała osadzonej sygnatury Primary Key Binding (cross-certification), gdy w tej sygnaturze pominięto podpakiet Key Flags. Metoda isSigningKey() dziedziczyła flagi SIGN_DATA z klucza głównego, podczas gdy verifyEmbeddedPrimaryKeyBinding() odczytywała tylko podpakiety sygnatury wiążącej i uznawała podklucz za niepodpisujący, przez co ten sam podklucz był jednocześnie zdolny do podpisywania i zwolniony z wymogu cross-certification.

W Bouncy Castle for Java przed 1.86 implementacja HQC ujawniała dane pochodzące z klucza prywatnego przez dwa kanały side-channel: arytmetyka GF(2^8) używała tablic wyszukiwania indeksowanych elementami pola, a próbnik wsparcia o stałej wadze kończył skanowanie przy pierwszej kolizji i zapisywał pozycje pod sekretnym indeksem. Atakujący obserwujący zachowanie cache lub czas deszyfrowania może odzyskać informacje o kluczu prywatnym HQC.

W bibliotece Bouncy Castle for Java przed wersją 1.86 występuje podatność typu side-channel w implementacji NTRU. Redukcja tajnych wartości za pomocą operatora % w trzech funkcjach pomocniczych powoduje, że czas wykonania zależy od operandu (dzielenie przez zmienną), co może pozwolić atakującemu na odzyskanie informacji o kluczu prywatnym NTRU poprzez pomiar czasu.

W implementacji MLS (RFC 9420) w Bouncy Castle for Java przed wersją 1.86 wartość leaf_index typu uint32 jest przechowywana jako signed int, co pozwala na przesłanie wartości z ustawionym najstarszym bitem, która dekoduje się jako liczba ujemna. Nieprawidłowe porównanie w GroupKeySet.SecretTree.hasLeaf i Group.validateRemove pozwala na obejście sprawdzania przynależności, co może prowadzić do ataku DoS poprzez nieograniczony wzrost listy węzłów i wyczerpanie sterty JVM.

Podatność typu niekontrolowane zużycie zasobów (CWE-400) w bibliotece Bouncy Castle for Java (wersje FIPS 2.1.0–2.1.1 oraz LTS 2.73.0–2.73.7) dotyczy natywnych implementacji algorytmów kryptograficznych AES i SHA. Może prowadzić do nadmiernej alokacji pamięci lub innych zasobów podczas przetwarzania danych przez te komponenty.