[Bug 281032] arc4random does not protect against VM forks

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: bugs@FreeBSD.org
          Reporter: jonas.boettiger@icloud.com

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.