The OpenSSL 3.0 rand
function's DRBG uses the getrandom()
system call to get 48 bytes of secure entropy from the kernel. It also uses other information like the system uptime, available RAM, and other factors public in user space. So if the getrandom()
function is compromised by an adversary using a rootkit, how would that affect OpenSSL DRBG in a practical attack? 48 bytes of entropy would be lost.
The rest of the factors (as far as I know), are not really hard to guess. Most are 32-bit integers with predictable ranges (such as the uptime being less than 1 year).
Would an attack using this information be easily achievable on a low-power PC?
This is not really a vulnerability in OpenSSL and can't be patched, so it would be interesting to explore developing this.
I see about 8 important values being used by OpenSSL besides system entropy:
getpid() = [pid]
sysinfo({uptime=3769, loads=[0, 0, 0], totalram=4114882560, freeram=3620483072, sharedram=778240, bufferram=15228928, totalswap=0, freeswap=0, procs=112, totalhigh=0, freehigh=0, mem_unit=1})
These are 32-bit and 64-bit integers. They are highly correlated, such as, if the uptime increases, the PID will increase.
If you know the server's serial number, you can search the specs, and the free ram can be found.
I have written a Linux rootkit that intercepts the getrandom()
call and returns the result of a DRBG I control (the seed). So I know the output of that 100% reliably. I was disappointed to find out that openssl uses more then one factor, and because of diffusion, it is not useful to me without these other factors.