Bug #71915 [Asn]: openssl_random_pseudo_bytes is not "fork-safe"

From: Date: Thu, 31 Mar 2016 13:21:58 +0000
Subject: Bug #71915 [Asn]: openssl_random_pseudo_bytes is not "fork-safe"
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-200268@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=71915&edit=1 ID: 71915 User updated by: mathieuk at gmail dot com Reported by: mathieuk at gmail dot com Summary: openssl_random_pseudo_bytes is not "fork-safe" Status: Assigned Type: Bug Package: OpenSSL related Operating System: any PHP Version: 5.6.19 Assigned To: bukka Block user comment: N Private report: N New Comment: @bukka Any idea yet on what direction you'd like to go? To follow up on some things: People are asking whether just reseeding on fork() isn't the way to go. @krakjoe even implemented [a POC PR](https://github.com/php/php-src/pull/1844) - although it's with PID and time (which doesn't help). I have some doubts about whether we are able to register that pthread_atfork callback soon enough for all SAPIs for it to be usable. Even if we are, that means that all requests are now getting a perf-hit regardless of if you even use openssl. That's something I tried to prevent in my PR. Previous Comments: ------------------------------------------------------------------------ [2016-03-29 20:42:22] bukka@php.net Ah I see what's the issue - finally read the links... :). Reading and thinking about it a bit more, the RAND_poll is probably reasonable. It would be good to know if there is any visible slow down though. Not that it would be a blocker but rather to see if we should have also consider some other solutions like addressing that in the SAPI's possibly (which might not be a great idea though). Anyway I will have to think about it a bit more so will leave this for a couple of days. ------------------------------------------------------------------------ [2016-03-29 19:33:24] mathieuk at gmail dot com I've moved it to https://github.com/php/php-src/pull/1843 @bukka Seeding with PID and time already happens after each call to RAND_bytes() and is what caused this behaviour in the first place. Apache's mod_ssl calls RAND_seed() with a few bytes from /dev/urandom (or egd) for each request - we could do that instead, but it seems like that's pretty much what RAND_poll() does. What are you seeing as the heavy part of RAND_poll? @krakjoe Right. This would work fine in mod_php, but maybe not FPM. I could force the bool to false in PHP_RINIT_FUNCTION(openssl). Think that'd work better? ------------------------------------------------------------------------ [2016-03-29 19:09:22] bukka@php.net Yeah there seems to be missing global init which should reset the value for each request (PHP_GINIT_FUNCTION). Then it should be fine and the entropy would be added for the first call of the openssl_random_pseudo_bytes in the request. It means it can be added multiple time if the same process is used for more requests (fpm) which I'm not sure is ideal but might not be an issue. Again I might be wrong. ------------------------------------------------------------------------ [2016-03-29 18:54:12] krakjoe@php.net Well, COW duplicated ... the same data whatever ... ------------------------------------------------------------------------ [2016-03-29 18:53:04] krakjoe@php.net It's not sensible to use module globals, these are duplicated on fork. So if the parent process has already called a function that results in reseed, or poll, the child process will not make the call ... ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=71915 -- Edit this bug report at https://bugs.php.net/bug.php?id=71915&edit=1

« previous php.bugs (#200268) next »