Source: cve-assign@fb.com
folly::secureRandom will re-use a buffer between parent and child processes when fork() is called. That will result in multiple forked children producing repeat (or similar) results. This affects HHVM 3.26 prior to 3.26.3 and the folly library between v2017.12.11.00 and v2018.08.09.00.
Multiple child processes spawned by applications using HHVM or the Folly library are vulnerable to a predictable random number generation (RNG) flaw. This allows attackers to potentially bypass security measures relying on randomness, such as cryptographic keys or session identifiers, leading to compromise of sensitive data and system control. The vulnerability stems from a shared buffer used by the folly::secureRandom function across forked processes.
Step 1: Process Initialization: A parent process using HHVM or a program using the Folly library initializes and calls folly::secureRandom.
Step 2: RNG Seeding: The folly::secureRandom function initializes an internal buffer with a seed value, likely from a system-provided source of entropy.
Step 3: Forking: The parent process calls the fork() system call to create a child process.
Step 4: Memory Inheritance: The child process inherits the parent's memory space, including the buffer used by folly::secureRandom and its seed.
Step 5: RNG Reuse: Both the parent and child processes now use the same seed value within their respective calls to folly::secureRandom.
Step 6: Predictable Output: Subsequent calls to folly::secureRandom in both parent and child processes generate predictable and potentially identical random numbers, because they are using the same seed and internal state.
Step 7: Exploitation: An attacker can leverage this predictability to guess or predict values generated by folly::secureRandom, potentially compromising security mechanisms that rely on its output.
The vulnerability lies in the folly::secureRandom function's implementation within the Folly library and its use within HHVM. When a process forks, the child process inherits the memory space of the parent, including the buffer used by folly::secureRandom. This buffer, intended to hold the seed for the RNG, is not re-initialized in the child process. Consequently, both parent and child processes, and all subsequent children, use the same seed, leading to predictable and repeated output from the RNG. The root cause is a lack of proper initialization of the RNG's internal state after a fork() system call. This results in a deterministic RNG instead of a cryptographically secure one. The flaw is not a buffer overflow or memory corruption directly, but a predictability issue.
While no specific APTs are directly linked to exploiting this vulnerability, any attacker targeting applications using HHVM or Folly could leverage it. The impact of the vulnerability could be used to facilitate other attacks. Not listed on CISA KEV.
Monitor for unusual patterns in the output of applications that use HHVM or Folly, especially if they are known to use folly::secureRandom for security-sensitive operations (e.g., key generation, session ID creation).
Analyze memory dumps of forked processes to identify shared memory regions containing the RNG's internal state.
Network traffic analysis: Look for patterns in data that should be random, but are consistently repeated across different processes or sessions.
File system monitoring: Check for the creation of files with predictable names or content, which could indicate the use of the flawed RNG.
Upgrade to the patched versions of HHVM (3.26.3 or later) or the Folly library (v2018.08.09.00 or later).
Review application code to identify and replace instances where folly::secureRandom is used for security-critical functions, if possible.
If upgrading is not immediately possible, consider mitigating the risk by using a different, more secure RNG implementation or by re-seeding the RNG in child processes after fork().
Implement process isolation techniques to limit the impact of a compromised child process.