I found two new bugs lead command execution flaw.
While using PHP-FPM, an attacker can fully bypass these security measures (open_basedir / execute commands).

1. stream_socket_client is not restricted by open_basedir
2. sendmail_path is marked as PHP_INI_SYSTEM but still can be modify by PHP_VALUE

An attacker can:
1. Send data to PHP-FPM daemon and set PHP_VALUE sendmail_path = /tmp/test
2. Create /tmp/test(base script, ELF) and chmod it to 777
3. Call mail() function, and PHP will invoke /tmp/test
4. Execute any command finally

A PoC: https://drive.google.com/file/d/1tcvV97abYcOaIgB_ZqVjQ46kmw2Yf9sL/view?usp=sharing

Not sure why we allow setting SYSTEM values via socket, this probably shouldn't happen.

According my further test, PHP_VALUE / PHP_ADMIN_VALUE can overwrite all the php.ini configuration settings including `php.ini only` settings.

https://github.com/php/php-src/blob/1ad08256f349fa513157437abc4feb245cce03fc/sapi/fpm/fpm/fpm_php.c#L116
Function `fpm_php_apply_defines` checks PHP configuration settings mode.

https://github.com/php/php-src/blob/1ad08256f349fa513157437abc4feb245cce03fc/sapi/fpm/fpm/fpm_php.c#L80
Function `fpm_php_apply_defines_ex` doesn't.

While parsing FastCGI requests, PHP-FPM will invoke `fpm_php_apply_defines_ex`.
That's all.

change package to fpm related

Jakub, could you please have a look at this?

This bug can overwrite php configuration settings even they are marked as PHP_INI_SYSTEM / PHP_INI_PERDIR or php.ini only. It will lead php security measures bypass or other security problems.

Will this issue be fixed?

Well I think that this is definitely on purpose. Basically the difference between php_value and php_admin_value is that the admin one allows setting PHP_INI_SYSTEM and changing that would break a lot of code so we can't do that I'm afraid.

Exposing of PHP_ADMIN_VALUE and PHP_VALUE is somehow unfortunate but it has been always there and we cannot change it without breaking a code. It's obviously on purpose too. I think we have to set a contract that one should never expose php-fpm publicly. It means it should always have a server in front of it (e.g. nginx or apache). To be honest I have never seen anyone exposing php-fpm and most installation will never do that so this is not actually a big issue. It would be definitely a bigger issue to break the existing servers.

I wouldn't be opposed to introduce a new option to ignore PHP_ADMIN_VALUE and PHP_VALUE that could potentially land in 7.3 as it's a feature. But I don't think there is anything we can do about this. It should be probably set to "Not a bug" though.

Hi bukka, this issue will lead PHP security measures bypassed (e.g. open_basedir) in a restricted environment. The contract is one hacker gain a webshell and want to execute commands or read files but he was restricted by disable_functions and open_basedir. 
Cause of PHP-FPM will listening at a TCP port or a UNIX socket file, the hacker is certainly able to access via the webshell.

I think you should read this as open_basedir is not really a security measure:
http://www.php.net/security-note.php

I don't think we consider any issues with that as a security issue as there are many ways to bypass it.

Since this is a PHP-FPM issue, it does certainly not affect Windows.

Having FPM listening on a public address seems a configuration issue, with a lot of security-related issues.

The reason one by default, FPM only allow local client (network port) or restricted user list (NDS).

So I don't think this have to be managed as a security bug.

> I think you should read this as open_basedir is not really a
> security measure:

Right, see also <https://externals.io/message/105606>
and <https://externals.io/message/115406>.

> So I don't think this have to be managed as a security bug.

ACK.

This behaviour is on purpose and its mitigation (optional disabling) is treated as a feature.