s2n-tls does not check if entropy_fd is still open

[matshch]

Problem:

Some programs close all non-standard file descriptors when creating a fork process to make some kind of a sandbox and to limit the attack surface. Unfortunately, this forces s2n-tls to stuck in the s2n_rand_urandom_impl loop if the library was already initialized in the parent process and when the child process tries to establish TLS connection, because the library expects entropy_fd to still be a valid file descriptor pointing to the /dev/urandom. In the best case the process is just stuck forever receiving EBADF errors, in the worst case RNG is initialized with some data stolen from another file descriptor.

Solution:

There are several ways to fix this:

• OpenSSL checks if the file descriptor is still valid and points to the same file before using data from it: https://github.com/openssl/openssl/blob/260d97229c467d17934ca3e2e0455b1b5c0994a6/providers/implementations/rands/seeding/rand_unix.c#L506-L523. Something similar can be done in s2n-tls.
• getrandom() function can be used instead of the file descriptor.
• Library can stop caching entropy_fd and properly open and close /dev/urandom for every reseeding.
• This behavior can be documented and clear instructions can be provided what is the proper way of working this around (including for users of AWS SDK).

Implications of each solution should be evaluated and the best fitting one should be implemented.

• Does this change what S2N sends over the wire? It changes which random numbers are used in cryptography in the described case of the file descriptor misuse (or if something is send at all). If /dev/urandom file descriptor is not closed by the code outside of this library, nothing changes.
• Does this change any public APIs? No.
• Which versions of TLS will this impact? Any.

Requirements / Acceptance Criteria:

s2n-tls should properly process errors during read of entropy_fd.

Users of the library should understand how to safely close file descriptors if they are required to take some action to fix this issue.

• Related Issues: AWS SDK breaks bultin:fetchurl builder and overrides OpenSSL engine  NixOS/nix#5947
• Will the Usage Guide or other documentation need to be updated? This issue can be addressed in the Usage Guide.
• Testing: Unit test can be created to replicate this behavior.
  • Will this change trigger SAW changes? I don't believe it should.
  • Should this change be fuzz tested? No.

[maddeleine]

Thanks for opening this issue. We'll look into it and see what we can do to fix this.