https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281032
Bug ID: 281032
Summary: arc4random does not protect against VM forks
Product: Base System
Version: Unspecified
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
Hi everyone!
I'm a maintainer of the Rust standard library. Our API team has decided to
include facilities for randomness into the standard library, in particular
giving access to the system's secure random number generator[1]. The idea here
is to make cryptographic strength the default to ensure security even when our
users don't make the best decisions. As obviously this API will be used by some
even when cryptographic strength isn't really needed – and even if it is –,
we'd like to choose the fastest API available on the system that still has the
required properties.
For this, given that it resides in userspace, arc4random_buf(3) seems to be the
ideal candidate, leading me to implement this new API on top of it on BSD-like
platforms[2]. Unfortunately, I've discovered that it does not reseed on VM
fork, making it considerably less secure than the getrandom(2) syscall and the
associated kernel RNG system which incorporates the VM generation ID into the
entropy pool upon receiving the respective ACPI signal and thereby ensures that
the random data returned will be different across VMs cloned from the same
snapshot.
As far as I could tell, the new Fenestras X RNG already includes a mechanism to
reseed arc4random by updating a generation counter in the vDSO whenever
necessary, but I could not confirm that this happens immediately on VM fork.
Regardless, the default Fortuna RNG definitely does not do so, thus weakening
the strength of arc4random_buf(3).
I think this would be fixed by arc4random unconditionally checking a kernel
entropy pool generation counter and immediately updating it in the kernel upon
VM fork, or by forwarding arc4random to getrandom and adding a vDSO version of
it like Linux did recently.
All the best,
Jonas
Links:
[1]: https://github.com/rust-lang/libs-team/issues/393
[2]: https://github.com/rust-lang/rust/pull/129201
--
You are receiving this mail because:
You are the assignee for the bug.
