CVE-2026-34240

Biblioteka jose akceptuje podpisy JWS ECDSA (ES256, ES256K, ES384, ES512) o niekanonicznej długości. Podczas weryfikacji funkcja jose_jwk_kty_ec:verify/4 dzieli surowy podpis na pół według jego rzeczywistej długości w bajtach, zamiast wymuszać stałą długość wymaganą przez RFC 7518 §3.4, a następnie dekoduje każdą połowę ignorując wiodące bajty zerowe. Atakujący posiadający jeden ważny token może dodawać wiodące bajty zerowe do połówek R i S, tworząc wiele różnych ciągów bajtów podpisu, które weryfikują się tym samym kluczem (malleability podpisu).

Nieefektywna złożoność algorytmiczna w erlang-jose pozwala nieuwierzytelnionemu zdalnemu atakującemu na wywołanie wyczerpania CPU (denial of service) poprzez przesłanie spreparowanego klucza RSA JSON Web Key. Gdy aplikacja parsuje niezaufany JWK przez publiczne API jose_jwk:from_binary/1 lub jose_jwk:from_map/1, klucz RSA zawierający d, e i n, ale bez parametrów chińskiego twierdzenia o resztach (p, q, dp, dq, qi), trafia do convert_sfm_to_crt/1, który próbuje odzyskać brakujące czynniki poprzez faktoryzację modułu. Gdy moduł nie da się rozłożyć na dwa czynniki, pętla wyszukiwania wykonuje kosztowną eksponencjację modularną w każdej iteracji i nigdy się nie kończy.

Podatność typu Observable Timing Discrepancy w bibliotece potatosalad jose pozwala na odzyskanie długoterminowego klucza prywatnego X25519 poprzez kanał boczny czasowy w czysto erlangowej implementacji Curve25519. Implementacja wykonuje mnożenie skalarne zależne od wartości bitów klucza prywatnego, co powoduje, że czas wykonania publicznych funkcji (np. scalarmult/2, x25519/2) zależy od klucza prywatnego. Podatność dotyczy wersji od 1.10.0 do 1.11.13.

Biblioteka jose eksportuje klucze prywatne szyfrowane hasłem w formacie PKCS#8 z zaszytymi parametrami PBES2: PBKDF2-HMAC-SHA256 z 2048 iteracjami i 8-bajtową solą, których nie można nadpisać. Wartości te są znacznie poniżej aktualnych zaleceń, co umożliwia tani atak offline na hasło i odzyskanie klucza prywatnego. Problem dotyczy wersji od 1.10.0 przed 1.11.13.

Funkcja jose_jwk:shared_secret/2 (w Elixir jako JOSE.JWK.shared_secret/2) wyprowadza wspólny sekret ECDH z dwóch JWK. Jej pierwsza klauzula dopasowuje tylko, gdy oba JWK mają ten sam moduł typu klucza (kty), a klauzula zapasowa ponownie wywołuje siebie jako shared_secret(from(YourJWK), from(MyJWK)). Ponieważ from/1 zwraca już sparsowany rekord jose_jwk bez zmian, przekazanie dwóch JWK o różnych typach kluczy (np. klucza EC i RSA) powoduje, że klauzula zapasowa wchodzi ponownie z identycznymi argumentami, tworząc nieograniczoną pętlę rekurencyjną ogonową, która nigdy nie kończy się i nie powoduje awarii.

Nieprawidłowa obsługa silnie skompresowanych danych (amplifikacja danych) w potatosalad jose (erlang-jose) pozwala zdalnemu atakującemu na wyczerpanie pamięci węzła za pomocą małego spreparowanego tokenu JWE. Funkcja jose_jwe_zip:uncompress/2 dekompresuje tekst jawny JWE skompresowany DEFLATE, gdy token zawiera opcjonalny nagłówek zip: DEF, wywołując zlib:inflate/2 na całym kontrolowanym przez atakującego strumieniu bez ograniczenia rozmiaru wyjścia lub współczynnika kompresji. Surowy DEFLATE osiąga współczynniki około 1000:1 na wysoce powtarzalnych danych, więc kilkukilobajtowy token rozpakowuje się do setek megabajtów lub gigabajtów w jednym wywołaniu.

Czysto-erlangowa implementacja odszyfrowywania RSAES-PKCS1-v1_5 w module jose_jwa_pkcs1 jest oracle'em paddingowym Bleichenbachera. Funkcja eme_pkcs1_decode/2 zwraca odzyskaną wiadomość, gdy odszyfrowany blok ma prawidłowy padding PKCS#1 v1.5, a w przeciwnym razie zwraca odrębny wynik błędu; rsaes_pkcs1_decrypt/2 dodatkowo zwraca {error, {badsize, _}} przy niepowodzeniu sprawdzenia długości. Implementacja nie stosuje środka zaradczego implicit rejection (RFC 8017 §7.2.2), więc jednobitowy sygnał zgodności paddingu wycieka do wywołującego. Ponieważ eksponencjacja modularna w dp/2 jest surowym, nieblindowanym crypto:mod_pow/3, sprawdzenie paddingu pozostaje rozróżnialne czasowo nawet gdy aplikacja normalizuje wszystkie błędy do jednej wartości.

Czysto-erlangowy fallback AES-GCM w jose_jwa_aes wyprowadza liczbę weryfikowanych bitów znacznika uwierzytelniania z samego znacznika dostarczonego przez atakującego. W klauzuli {aes_gcm, Bits} funkcji block_decrypt/4 przychodzący znacznik jest sprawdzany tylko przez is_binary/1, bez kontroli długości. Weryfikacja w gcm_block_decrypt/6 oblicza TBits = bit_size(T) i porównuje tylko te bity rzeczywistego 128-bitowego znacznika. Atakujący kontrolujący token JWE może skrócić znacznik uwierzytelniania do zaledwie 8 bitów, więc sprawdzane jest tylko 8 bitów, co zmniejsza odporność na fałszowanie z 2^-128 do 2^-8.