Bug #73342 [Ver]: Vulnerability in php-fpm by changing stdin to non-blocking

From: Date: Sun, 25 Feb 2018 19:21:05 +0000
Subject: Bug #73342 [Ver]: Vulnerability in php-fpm by changing stdin to non-blocking
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-214101@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=73342&edit=1 ID: 73342 Updated by: bukka@php.net Reported by: xuavis at gmail dot com Summary: Vulnerability in php-fpm by changing stdin to non-blocking Status: Verified Type: Bug Package: FPM related Operating System: Ubuntu 16.04 PHP Version: 7.0Git-2016-10-18 (Git) Assigned To: bukka Block user comment: N Private report: N New Comment: @nikic I think that the reason why FPM cares about STDIN is to conform FastCGI spec - namely section 2.2 ( http://www.mit.edu/~yandros/doc/specs/fcgi-spec.html#S2.2 ) that states "FCGI_LISTENSOCK_FILENO equals STDIN_FILENO". I guess it's because maybe some FastCGI application could access the data directly from the record but not really sure why. I can't really see the reason for that in the PHP case. I don't see any side effects of the patch at the moment but it might need a bit more thinking and testing. Previous Comments: ------------------------------------------------------------------------ [2018-02-23 21:10:52] nikic@php.net Related To: Bug #67796 ------------------------------------------------------------------------ [2018-02-23 20:48:52] nikic@php.net Related To: Bug #73056 ------------------------------------------------------------------------ [2018-02-23 20:41:40] nikic@php.net I think the patch from the first comment only works around the problem ... the real question is this: Why does FPM care about STDIN at all? After some looking around, this seems to be what happens: * wp->listening_socket is what we actually want to listen on. * fpm_globals.listening_socket is always 0 (effectively STDIN), because that's what the global is initialized to. It's never changed. * fpm_run() always returns fpm_globals.listening_socket and that's what fcgi listens on. * to make things line up fpm_stdio_init_child() does a dup2(wp->listening_socket, STDIN_FILENO). So effectively we take the listening socket, dup2 it to STDIN and then listen on STDIN. The following patch removes the indirection through STDIN: diff --git a/sapi/fpm/fpm/fpm_children.c b/sapi/fpm/fpm/fpm_children.c index b48fa54..4ee316b 100644 --- a/sapi/fpm/fpm/fpm_children.c +++ b/sapi/fpm/fpm/fpm_children.c @@ -146,6 +146,7 @@ static struct fpm_child_s *fpm_child_find(pid_t pid) /* {{{ */ static void fpm_child_init(struct fpm_worker_pool_s *wp) /* {{{ */ { fpm_globals.max_requests = wp->config->pm_max_requests; + fpm_globals.listening_socket = dup(wp->listening_socket); if (0 > fpm_stdio_init_child(wp) || 0 > fpm_log_init_child(wp) || diff --git a/sapi/fpm/fpm/fpm_stdio.c b/sapi/fpm/fpm/fpm_stdio.c index 4072017..76e8b32 100644 --- a/sapi/fpm/fpm/fpm_stdio.c +++ b/sapi/fpm/fpm/fpm_stdio.c @@ -103,12 +103,6 @@ int fpm_stdio_init_child(struct fpm_worker_pool_s *wp) /* {{{ */ fpm_globals.error_log_fd = -1; zlog_set_fd(-1); - if (wp->listening_socket != STDIN_FILENO) { - if (0 > dup2(wp->listening_socket, STDIN_FILENO)) { - zlog(ZLOG_SYSERROR, "failed to init child stdio: dup2()"); - return -1; - } - } return 0; } /* }}} */ This also resolves the issue for me. However, I don't know if this has any side-effects, because something else relies on the STDIN mapping. ------------------------------------------------------------------------ [2018-02-23 16:55:15] nikic@php.net Related To: Bug #70185 ------------------------------------------------------------------------ [2018-02-23 16:54:23] nikic@php.net Related To: Bug #75968 ------------------------------------------------------------------------ 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=73342 -- Edit this bug report at https://bugs.php.net/bug.php?id=73342&edit=1

« previous php.bugs (#214101) next »