Bug #71915 [Asn]: openssl_random_pseudo_bytes is not "fork-safe"
| From: | mathieuk at gmail dot com | 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