security issue with phpSuExec / php.ini settings

[qwerty]

We use cpanel and phpsuexec ..

We disable functions inside the server's main php.ini

I just noticed today that if a customer uploads an empty php.ini (or with contents, but empty will work too) inside their public_html that NONE of the disabled functions are disabled any longer.

eg. if you disable shell_exec, system etc inside your main php.ini and a customer uploads an empty php.ini to their space, they can use those functions.

I don't think this used to be the case, even with phpsuexec and suspect it may be a bug/hole.. can someone confirm?

The reason I don't think this used to be like this is because I remember quite clearly that we tried enabling a disabled function for a customer, even trying custom php.ini in customer's root dir, but it never worked ie. functions which were disabled in the main php.ini COULD NOT be re-enabled on a per-customer basis. But now it seems this is possible ... ?!

And it's not just the disable_functions that is reset/overriden when a customer uploads an empty php.ini, ALL of your php.ini settings are reset to the defaults or whatever the customer puts inside their php.ini - ie. any restrictions you placed in the main server's php.ini are no longer applicable for this customer.

[hostultra]

Its supposed to work this way.
This is because phpsuexec runs PHP in CGI mode.

If its run as an apache module the user cant use his own php.ini


Also maybe unrelated to this issue but if any of the exec, system, passthru etc... functions are enabled it is possible for the user override any php restriction as executed programs are not subject to php restrictions such as safemode etc...

[panayot]

yes I just checked on my server: disabled functions can indeed be enabled by the user through a local php.ini file.

[Faldran]

Wow, took you all long time to notice that... I have known that for almost 2 years now.. ( man how times flies. )
That is why you should always watch your clients... i.e. we use a script and locate and/or find to find new php.ini and watch what people use it for.

Not much worse than many things you can by-pass with .htaccess

As always you should watch who you give accounts too and also watch what they do with it.

[sparek-3]

This can be a downside, but the other way to view it, is because you are using phpsuexec any php script will run as that user. So if users do not have access to certain binaries, they won't be able to run them. Also if they try to create files, those files will be owned by them, so you can easily trace them. Its just one of those things you have to deal with.

[panayot]

Wow, took you all long time to notice that... I have known that for almost 2 years now.. ( man how times flies. )
That is why you should always watch your clients... i.e. we use a script and locate and/or find to find new php.ini and watch what people use it for.

Not much worse than many things you can by-pass with .htaccess

As always you should watch who you give accounts too and also watch what they do with it.

Just got my first server 2 weeks ago. I would be gratefull indeed if you could give me an idea how to write such a monitoring script!

I wanted to use a similar script to watch /tmp directory for executable files uploaded (or other suspicious)

perhaps something using find and sending mail in case of a match.

[qwerty]

I think you're wrong people ...

I remember quite clearly a couple of months ago a customer needing the 'exec' function and since it was disabled in the main php.ini there was nothing we could do. I had tried everything to un-disable it by placing a custom php.ini in the customer's homedir, but it didn't do jack ..

[hostultra]

I think you're wrong people ...

I remember quite clearly a couple of months ago a customer needing the 'exec' function and since it was disabled in the main php.ini there was nothing we could do. I had tried everything to un-disable it by placing a custom php.ini in the customer's homedir, but it didn't do jack ..

custom php.ini must be in the same folder as the .php file and this only works when phpsuexec is on.

[qwerty]

custom php.ini must be in the same folder as the .php file and this only works when phpsuexec is on.

And the sky is blue. What's your point? I know that.

But an empty php.ini shouldn't automatically un-disable disabled functions (that were disabled in the main server's php.ini) and it does. It didn't use to do so. Get it?