Podatność w bibliotece Bouncy Castle for Java FIPS (BC-FJA) przed wersją 2.1.3 powoduje nieskończone blokowanie wątku aplikacji podczas pobierania entropii na platformach Intel. Może to doprowadzić do całkowitej odmowy dostępu do usługi (DoS) dla aplikacji korzystających z natywnego źródła entropii.
▸ Pokaż oryginał (EN)
In Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 2.1.3, the native entropy source used on Intel platforms retried the CPU entropy instructions without any bound. RDSEED and RDRAND report failure through their carry flag, and the JNI seeding routine spun re-issuing the instruction for as long as that flag stayed clear, so a persistent failure of the on-chip entropy source - whether from a hardware fault, from the underlying DRBG being exhausted by contention across many cores, or from a hypervisor that does not provide the instruction - left the calling thread looping indefinitely inside the JNI call, where it could be neither interrupted nor timed out. Any operation drawing from the native entropy source could therefore hang, denying service to the application. The retry loops are now bounded (200 attempts for RDSEED and 20 for RDRAND, twice the baselines given in Intel's Digital Random Number Generator software implementation guide), pausing between attempts and, on exhaustion, clearing any partially written buffer and throwing rather than continuing to spin. The clear is performed by an un-elidable memzero, which uses a volatile pointer and an assembly memory barrier so that a compiler cannot optimise the erase away as a dead store. Bouncy Castle for Java (bcprov) is not affected, as it has no native entropy source; the 1.0.X and 2.0.X FIPS series are not affected.
Natywna procedura seedowania JNI na platformach Intel korzysta z instrukcji RDSEED i RDRAND, które sygnalizują błąd poprzez flagę przeniesienia (carry flag). W wersjach przed 2.1.3 pętla ponawiania prób nie miała żadnego ograniczenia liczby iteracji — w przypadku trwałego niepowodzenia instrukcji (np. wskutek awarii sprzętowej, wyczerpania wewnętrznego DRBG przez rywalizację wielu rdzeni lub braku wsparcia instrukcji przez hiperwizor) wątek wpadał w nieskończoną pętlę wewnątrz wywołania JNI. Pętla ta nie mogła być przerwana ani zakończona przez timeout, co prowadziło do trwałego zawieszenia wątku. Poprawka ogranicza liczbę prób do 200 dla RDSEED i 20 dla RDRAND, wprowadza przerwy między próbami oraz po wyczerpaniu limitu zgłasza wyjątek i bezpiecznie zeruje bufor przy użyciu nieoptymalizowalnego przez kompilator wywołania memzero.
Atakujący lub nieprawidłowe środowisko uruchomieniowe (np. hiperwizor nieobsługujący instrukcji entropii) może doprowadzić do trwałego zawieszenia wątków aplikacji korzystających z natywnego źródła entropii, skutkując odmową dostępu do usługi (DoS) dla całej aplikacji.
Należy zaktualizować BC-FJA do wersji bc-fips 2.1.3 lub nowszej. Szczegóły dostępne w referencjach producenta: https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%908798
Bouncy Castle for Java FIPS (BC-FJA) w serii 2.1.X przed wersją bc-fips 2.1.3, uruchamiany na platformach Intel. Serie 1.0.X i 2.0.X FIPS oraz standardowa biblioteka Bouncy Castle for Java (bcprov) nie są podatne.
Podatność dotyczy wyłącznie środowisk uruchomieniowych na platformach Intel, gdzie natywne instrukcje entropii (RDSEED/RDRAND) mogą trwale zawodzić — w szczególności dotyczy to środowisk wirtualizowanych (hiperwizory niezapewniające obsługi tych instrukcji) oraz systemów wielordzeniowych pod dużym obciążeniem. Biblioteka bcprov (wersja nieposiadająca natywnego źródła entropii) nie jest podatna.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber