В Bouncy Castle для Java FIPS (BC-FJA) до версии bc-fips 2.1.3 собственный источник энтропии, используемый на платформах Intel, повторял инструкции энтропии ЦП без каких-либо ограничений. RDSEED и RDRAND сообщают об ошибке через свой флаг переноса, а процедура заполнения JNI запускает повторную выдачу инструкции до тех пор, пока этот флаг остается свободным, поэтому постоянный сбой встроенного источника энтропии - будь то из-за аппаратного сбоя, из-за исчерпания базового DRBG из-за конкуренции между многими ядрами или из-за гипервизора, который не предоставляет инструкцию - вызывающий поток зацикливается на неопределенный срок внутри вызова JNI, где его нельзя ни прервать, ни время ожидания истекло. Таким образом, любая операция, извлекаемая из собственного источника энтропии, может зависнуть, что приведет к отказу в обслуживании приложения. Циклы повторов теперь ограничены (200 попыток для RDSEED и 20 для RDRAND, что в два раза превышает базовые показатели, указанные в руководстве по реализации программного обеспечения Intel Random Number Generator), с паузой между попытками и, при исчерпании, очисткой любого частично записанного буфера и выдачей вместо продолжения вращения.
Очистка выполняется с помощью неисключаемого memzero, который использует изменчивый указатель и барьер памяти сборки, так что компилятор не может оптимизировать стирание как мертвое хранилище. Bouncy Castle для Java (bcprov) не затрагивается, поскольку у него нет собственного источника энтропии; серии FIPS 1.0.X и 2.0.X не затрагиваются.
Показать оригинальное описание (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.
Характеристики атаки
Последствия
Строка CVSS v4.0