I see that the type was changed from Security to a "Feature Request". I am not saying that this change is wrong but I'd like to provide more information to describe why this has an important security impact.

It is common to add some security measures when installing a PHP environment. Things like "open_basedir", "disable_functions", etc. This way if a website is compromised you can limit the impact in other websites or services in the same server.

With the current PHP configuration options it is not possible to prevent users from setting environment variables like LD_PRELOAD. Due to this a user can upload a custom library and use LD_PRELOAD to execute code from that library that will effectively bypass any of the previous restrictions.

In other words, a user that can execute custom PHP code can easily bypass restrictions like "open_basedir" or "disabled_functions" because systems administrators do not have a way to prevent users from setting LD_PRELOAD (other than disabling "putenv" function).

I think this has a significant impact in security.

and how is that user supposed to load any binary code in a sensible setup with dl() not enabled to begin with? LD_PRELOAD in the middle of the process is completly meaningless

You can use "strace" to see what external functions some PHP functions. For example the "mail" function calls "geteuid". So you can code a library that reimplements that function (i.e. "geteuid") and do whatever you want. Then you use LD_PRELOAD to load your custom library and then call the PHP function (i.e. "mail") so it will trigger your custom code.

You have a good example here using these very same functions: https://github.com/0verl0ad/sifilis-PoC/

when your setup is able to start a suid binary like sendmail and mail() is not disabled you have much more things to worry

again: in a *sensibke* setup with security in mind there are nol libraries loaded and binaries executed at the runtime of a script, all the php extensions and tehir libraries are lareay loaded long before you can call setenv()

To clarify, the "Security" category is for bugs that need to be kept private until the fix has been released. The classification change is not supposed to imply that there is no relation to security here, just that it doesn't need to be confidential.

Thank you for your clarification Nikic. I just wanted to give more information about the problem so the implications are better understood. If you consider this is the right category, that is totally fine for me.

Regarding disabling mail() for a secure setup, although I agree it would be safer, it is an expected feature for most of legit users so disabling it is not as an easy choice as disabling shell_exec(). For this reason it is usually enabled and the use of LD_PRELOAD to bypass restrictions is well known among web hackers (both white and black hats)

i don't know any software which don't support smtp via phpmailer and mail() is in disabled_functions() here since 2002 which is 18 years now

My point here is to have a sensible solution that has a minimal impact on end users and having a way to limit what environment variables a user is able to set seems the right way.

There are users that still use mail() in their custom code. I agree that disabling mail() would solve the problem (in case there aren't any other common external runtime calls) but that would have impact in some users. Disabling putenv() will also solve the problem but again, although most of the software does not require it, it is a feature that some users might miss.

In any case, I already said that I am ok with considering this a feature request. I just wanted to give some more information regarding some of its security implications.

I think it could be useful to have some configuration that allowed to do this as it was possible in the past. If you do not think that is the case, feel free to disregard this bug report and mark it as wontfix.

> I don't know any software which don't support smtp via phpmailer and mail() is in disabled_functions() here since 2002 which is 18 years now.

I am afraid that Wordpress (version 5.4.1, latest as of today) relies by default on mail(). Despite using PHPMailer, it seems to default to mail(). With mail() in disabled_functions, things like password reset mails won't work.

I've been trying to workaround this but there isn't a good alternative. I wish this wasn't disregarded so easily.

https://www.siteground.com/tutorials/wordpress/use-smtp/

Yes, it is possible to do it if you install a plugin to send mails via SMTP using localhost. The default wordpress installation does not allow that.