The unexpected behavior of openssl_random_pseudo_bytes () leads to a fatal loss of robustness
Good day to all.
Recently, in one of the projects we encountered the following problem - the openssl_random_pseudo_bytes () function produced duplicate pseudo-random sequences!
It can not be, because it can never be! - Anyone who has read the documentation for this feature will say. And, yes, $ crypto_strong regularly issued TRUE.
And nevertheless, when inserting into the database, uniqueness errors were packed in batches and the log confirmed that 32-byte sequences were repeatedly generated at different intervals, from days to weeks. The investigation took a whole month. Now I am 99% sure that the reason has been found - but I will be grateful if Habragiteli will confirm or deny my conclusions.
')
But it was a combination of three products at once:
Simplifiedly, what is happening looks like this - at start, it creates the first copy of the PCP, which starts with the random generator OpenSSL. And then - Apache creates and uses forks, including copying the initial state of the random generator.
Since the random generator is also tied to the PID process, the problem does not appear immediately. Since on Linux the typical maximum value for PID is 65536, it is approximately after such a number of requests to the web server that the pseudo-random sequences issued will start repeating. More accurate technical details are better to get in the article above in the OpenSLL Knowledge Base.
The problem is aggravated by the fact that the best recommended countering methods (Call RAND_seed after a fork and Call RAND_poll after a fork) are not applicable on PCPs, since these OpenSSL functions are simply not available from PCPs.
Unfortunately, I did not manage to find in the network adequate materials on this problem, with the exception of the OpenSLL article already cited, but it does not describe a specific link of Apache + PHP + OpenSSL. But there are strongly recommended articles to use openssl_random_pseudo_bytes () as a cryptographic RNG - abound.
But the king is naked!
As a result, I had to simply abandon the use of openssl_random_pseudo_bytes () and switch to direct reading from / dev / urandom. Not the most brilliant solution - but sufficient in our case.
Since the author is not an expert in the field of cryptography and my conclusions may be incorrect / incomplete, and the problem is more than serious, given the prevalence of recommendations on the use of openssl_random_pseudo_bytes (), I will definitely study all the comments of experts and possibly correct / add (or delete if fundamentally wrong) article. Also, if the conclusions are confirmed, it will be necessary to make additions to the documentation of PCPs and proposals for adding RAND_seed / RAND_poll and / or their calls when starting the script in PCP.
Important! Apache should work in prefork mode (MPM prefork). The version of PCP with which the problem was checked is 5.5.x, but, presumably, it will be played in any version that has openssl_random_pseudo_bytes ()
PS I unsubscribed at security@php.net - almost a month ago. No answer, no greeting. Or not received. Or ignored. I do not know.
So I bring the article back to online.
Recently, in one of the projects we encountered the following problem - the openssl_random_pseudo_bytes () function produced duplicate pseudo-random sequences!
It can not be, because it can never be! - Anyone who has read the documentation for this feature will say. And, yes, $ crypto_strong regularly issued TRUE.
And nevertheless, when inserting into the database, uniqueness errors were packed in batches and the log confirmed that 32-byte sequences were repeatedly generated at different intervals, from days to weeks. The investigation took a whole month. Now I am 99% sure that the reason has been found - but I will be grateful if Habragiteli will confirm or deny my conclusions.
')
But it was a combination of three products at once:
- Apache working with prefork MPM
- PHP has limited support for OpenSSL features
- And the OpenSSL library itself has Random fork-safety
Simplifiedly, what is happening looks like this - at start, it creates the first copy of the PCP, which starts with the random generator OpenSSL. And then - Apache creates and uses forks, including copying the initial state of the random generator.
Since the random generator is also tied to the PID process, the problem does not appear immediately. Since on Linux the typical maximum value for PID is 65536, it is approximately after such a number of requests to the web server that the pseudo-random sequences issued will start repeating. More accurate technical details are better to get in the article above in the OpenSLL Knowledge Base.
The problem is aggravated by the fact that the best recommended countering methods (Call RAND_seed after a fork and Call RAND_poll after a fork) are not applicable on PCPs, since these OpenSSL functions are simply not available from PCPs.
Unfortunately, I did not manage to find in the network adequate materials on this problem, with the exception of the OpenSLL article already cited, but it does not describe a specific link of Apache + PHP + OpenSSL. But there are strongly recommended articles to use openssl_random_pseudo_bytes () as a cryptographic RNG - abound.
But the king is naked!
As a result, I had to simply abandon the use of openssl_random_pseudo_bytes () and switch to direct reading from / dev / urandom. Not the most brilliant solution - but sufficient in our case.
Since the author is not an expert in the field of cryptography and my conclusions may be incorrect / incomplete, and the problem is more than serious, given the prevalence of recommendations on the use of openssl_random_pseudo_bytes (), I will definitely study all the comments of experts and possibly correct / add (or delete if fundamentally wrong) article. Also, if the conclusions are confirmed, it will be necessary to make additions to the documentation of PCPs and proposals for adding RAND_seed / RAND_poll and / or their calls when starting the script in PCP.
Important! Apache should work in prefork mode (MPM prefork). The version of PCP with which the problem was checked is 5.5.x, but, presumably, it will be played in any version that has openssl_random_pseudo_bytes ()
PS I unsubscribed at security@php.net - almost a month ago. No answer, no greeting. Or not received. Or ignored. I do not know.
So I bring the article back to online.
Source: https://habr.com/ru/post/277779/
All Articles