Affected Users:
Applications using wolfSSL’s OpenSSL compatibility layer before wolfSSL version 5.8.2 that call both RAND_bytes() and fork() operations. This does not affect internal TLS operations or applications that do not explicitly use RAND_bytes().
Summary:
A vulnerability was discovered in wolfSSL’s OpenSSL compatibility layer where the RAND_poll() function was not behaving as expected, leading to potentially predictable values returned from RAND_bytes() after a fork() system call. When an application calls fork() to create a child process, both the parent and child processes would inherit the same internal random number generator state. Without proper reseeding, this could result in both processes generating identical “random” numbers, which could compromise cryptographic operations that depend on unpredictable random values.
This issue specifically affects applications that do all of the following:
- Use wolfSSL’s OpenSSL compatibility layer
- Explicitly call
RAND_bytes()to generate random numbers - Perform
fork()operations to create child processes
The vulnerability does not impact wolfSSL’s internal TLS operations, which use separate random number generation mechanisms.
While OpenSSL’s documentation for RAND_bytes() states that it is not safe for use with fork() without first calling RAND_poll(), many applications may not be aware of this requirement. To provide better compatibility and security, wolfSSL has implemented additional improvements beyond fixing RAND_poll(). The Hash-DRBG (Deterministic Random Bit Generator) now automatically detects when it is running in a new process after a fork() call and reseeds itself, making RAND_bytes() behave more safely by default, similar to recent versions of OpenSSL.
We would like to thank Per Allansson from Appgate for discovering and responsibly reporting this vulnerability to our team.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now