Server compromize by overiding php.ini

[kiat]

I am runing suPHP with PHP safe mode to disable dengerous command in PHP but in some circumstance that a website allow upload or it was a security hole in a script that allow external files to store. It could upload php.ini to overide defult php.ini and upload php shell together with rootkit and install rootkit from php shell to compromize the server. Is there anyway I can prevent this event to happen?

[jandafields]

This is directly from CPanel Manual. I'm not sure if it applies, but it seems to possibly:


The suphp.conf file includes a section called [phprc_paths] that can be used to override the standard handling of php.ini. To lock a particular PHP handler to its default php.ini file, simply uncomment the appropriate line under [phprc_paths]. There is also a configuration directive supported by mod_suphp in httpd.conf and .htaccess files called suPHP_ConfigPath that sets the path to the php.ini file. To prevent the use of this directive in .htaccess files, remove "Options" from the Apache AllowOverride setting. Note that the [phprc_paths] set in suphp.conf take precedence over any suPHP_ConfigPath settings.

[rustelekom]

removing Options is not good idea. Suphp offer more elegant way to close such security problem - you only need modify one directive in suphp.c Unfortunately, it is hard for realize by unexperienced user with cur.rent structure of EasyApache.

[chirpy]

There is no reason to modify the suphp source code. You can achieve the protection by following the information in jandafields post.

[weetabix]

is there a safe way to let users have their own php.ini?

[chirpy]

Probably not. PHP has a pretty useless security model (especially for the way it is promoted) and such restrictions, while they can slow hackers down, won't actually stop exploitation as hackers can simply call a perl script that can do whatever your server file permissions allow. This is actually how most exploits through PHP work. The restrictions you impose are really a crude way of restricting vulnerabilities that exist in poorly written PHP scripts that the language encourages. Really, the restrictions you impose on PHP are better seen as ways of limiting resources that your clients can use on the server. One typical example is badly written scripts that assume to bypass the restriction of memory allocation that you limit in php.ini

[weetabix]

ok, so what you are saying is, that it doesn't really matter from a security perspective if we allow customers to use their own php.ini?


or am i totally getting you wrong?

[chirpy]

Yes and No. It may well help with the automated type of compromise targetting vulnerable PHP applications. It probably won't stop a determined hacker from exploiting a vulnerability in such an application.

What it won't really affect is what a customer can do on their web hosting account apart from resource restrictions that you want to impose to protect the server as a whole.

suPHP, however, is probably an essential option to help protect your server where you offer web hosting to prevent cross-account exploitation. This is where, when running under the nobody account, any user on the server (and any hacking exploit) will have read access to all other accounts web files and most likely write access to many other accounts directories and files.

A typical exploit that uses that "feature" of the default configuration of PHP (i.e. without suPHP) is where you see all your clients index.html pages infected with an iframe hack. Enabling suPHP should effectively prevent that from affecting anything other than the account where the hacker obtained access.

[rustelekom]

I cannot understand why Cpanel team stick with untouched default suphp installation. if server owner follow your recommendation he will lost one of big SuPHP features -customizing php settings per user choice. Does you mean that it is not useful option? I cannot agree with you. Uou are offer only two choice - disable php customizing (per user basis) or open big hole in server security. Why your recommendation restricted so much? If you will follow suPHP author recommendation you will be able use third way and you could use both great suphp feature: customizing php setting and in the same time do not allow to customer modify php settings without admin knowledge and also you will not lost .htaccess functionality by disabling Options.
If anyone can confirm that both feature is not usefull - then i will just laugh - about 50% of customer scripts require php customization otherwise they just not will work.

[brianoz]

... It could upload php.ini to overide defult php.ini and upload php shell together with rootkit and install rootkit from php shell to compromize the server. Is there anyway I can prevent this event to happen?

The beginner's mistake here is thinking that PHP security is the way to keep the machine safe. The real problem here is your insecure file storage script that allowed a php.ini file to be overwritten. After all, if they can overwrite a php.ini file they can overwrite any other file too!

The best blanket "fix" here is to install mod_security with a good ruleset, which catches many of these. Also install CSF which will often be able to identify and block security probes (via mod_security audit log) from hackers before they have a chance to try much.

Note that nothing replaces getting rid of these insecure scripts, or updating them so they are not insecure. At the end of the day even mod_security cannot keep you safe against everything.

I cannot understand why Cpanel team stick with untouched default suphp installation. if server owner follow your recommendation he will lost one of big SuPHP features -customizing php settings per user choice. Does you mean that it is not useful option? I cannot agree with you.

I'm not sure what you base this on; of course a user can customise PHP with their own php.ini file, what would stop them? The method (I think) you're proposing is only an alternative method that I can't yet see has any value over the more-or-less standard php.ini method.

If anyone can confirm that both feature is not usefull - then i will just laugh - about 50% of customer scripts require php customization otherwise they just not will work.

If 50% of PHP scripts require PHP customisation (I'm assuming you mean via php.ini) then your PHP settings are set up incorrectly; that's certainly not the case on my server where it's rare (maybe 5-10% at absolute most) for a site to need a php.ini file.

[fenixer]

If 50% of PHP scripts require PHP customisation (I'm assuming you mean via php.ini) then your PHP settings are set up incorrectly; that's certainly not the case on my server where it's rare (maybe 5-10% at absolute most) for a site to need a php.ini file.

Oh come on!!! I am reading about security and suphp and I see people talking about it as talking about Descartes or Kant philosophy..........

register_globals may be on or off....... in my case too, 50% need it to be on, as 50% need it to be off....... it is not a question of global configurations (off of course). I do not need to give classes of php programming to a "stupid" client who does not take care of bringing up variables...

I assume that: if a client can (because we want through suphp.conf) modify php.ini rules, hacker could also, because hacker (through php) is just equal to client.

There are two importants questions about suphp:

1 - http://www.watters.ws/wiki/index.php...ile_with_suPHP
If a do that, that .htaccess directive should apply php.ini to all subdirectories just like .htaccess php flags do running DSO? may that suPHP_ConfigPat and the php.ini directives applies to .htaccess directory and subdirectories?

2 - Could I, through suphp.conf, allow certain php.ini directives to be overriden by clients (and their php.inis) but some other php.ini directives to be not overwritten??
By example, I configure suphp as:
- I really do not care if clients configure register_globals through their php.ini
- HEY, I do not care php.ini of my clients... register_globals IS ALWAYS NO..

I think these two questions are the most important.... and they can be answered simply using "yes" or "no"... depend of them I will use suphp or keep using DSO.

Thanks.

[stdout]

register_globals may be on or off....... in my case too, 50% need it to be on, as 50% need it to be off....... it is not a question of global configurations (off of course). I do not need to give classes of php programming to a "stupid" client who does not take care of bringing up variables...

Calling your customer stupid because they're inexperienced or don't have the time to google and troubleshoot 3rd party script insecurities is certainly not the way to think of them. At least be smart about it and refer them to a general how-to or informational page to give them a fresher understanding of what's happening.

My two cents here is that there will always be vulnerabilities. Be it from your direct customer script or a reseller's enduser's scripts - users will always have insecure/outdated 3rd party script installations.

* Be proactive.
Parse your access_log routinely for malicious requests.
Then apply new modsec rules to prevent reoccurring hackings.

* Set up your own "exec_dir" and disable "register_globals" server-wide.
Create a seperate "executable directory" such as "/usr/local/phpbin/" and only copy the bare essentials to it. If a user requires register_globals on, let them know how to enable it using a local php.ini or .htaccess

[rustelekom]

There are two importants questions about suphp:

1 - http://www.watters.ws/wiki/index.php...ile_with_suPHP
If a do that, that .htaccess directive should apply php.ini to all subdirectories just like .htaccess php flags do running DSO? may that suPHP_ConfigPat and the php.ini directives applies to .htaccess directory and subdirectories?

suPHP only work with php.ini. And only one php.ini can be used on one virtual host. All folder, files under folder which set in suPHP_ConfigPath apply to same PHP settings.

2 - Could I, through suphp.conf, allow certain php.ini directives to be overriden by clients (and their php.inis) but some other php.ini directives to be not overwritten??
By example, I configure suphp as:
- I really do not care if clients configure register_globals through their php.ini
- HEY, I do not care php.ini of my clients... register_globals IS ALWAYS NO..
Thanks.

No, you cannot. But, you can modify user php.ini and hold it in some place where user cannot edit it. Therefore you can restrict user with directives, functions etc. which you want allow to him.

[stdout]

Only if suPHP_ConfigPath is set, will one php.ini be used.
If unset, a php.ini is required under the directory where the script is executing from.

A smart move would be to set the suPHP_ConfigPath and have an admin chattr +i php.ini and .htaccess after your customizations, preventing hackers from applying their custom php.ini tweaks.

[fenixer]

Calling your customer stupid because they're inexperienced or don't have the time to google and troubleshoot 3rd party script insecurities is certainly not the way to think of them. At least be smart about it and refer them to a general how-to or informational page to give them a fresher understanding of what's happening.

Well, "stdout", if you read I just have written "stupid", not stupid..... I am spanish and my english sometimes is poor, so I use ""..... the right word maybe is newbie?.. this is less offensive, but the question is I cannot force register_globals off to just explain many clients why their scripts run perfectly at their machines, or at any other hosting servers but mine, due to their poor programming skills using global variables, and point to php tutorials.... I just need to reffer them to a htaccess tutorial explaining how they can override this register_global setting using a php_flag and fix by themselves.... That's all....... most cases client have problems with globals vars does not have nothing to do with 3rd party scripts, but own ones; but surely I cannot enforce to give php tutorials to nobody because problems may be quickly multiplied and have many clients and many servers.

Once explained this, just give thanks for all your answers... now I have understood finally how suphp works at all.....

But I think it is not a good sollution for me at all, since I need clients controlling by their selves some php directives (only some, as DSO with .htaccess options do), and for me it should be very difficult to accept as a IT support job, modifying php.inis for the 1000-1500 accounts currently supported... It may be fantastic I simply can give plenty access clients to their php.ini, but only allowing the overridings of some directives from the global php.ini ones.... so the security level were controlled.

Also..........mmmmmm....

* Set up your own "exec_dir" and disable "register_globals" server-wide.
Create a seperate "executable directory" such as "/usr/local/phpbin/" and only copy the bare essentials to it. If a user requires register_globals on, let them know how to enable it using a local php.ini or .htaccess

I think that exec_dir need safe_mode to be on?????? isn't it????
The only sollution I know and I am testing is to quickly patch PHP folder before easyapache starts to compile with:
http://www.kyberdigi.cz/projects/execdir/english.html

how do you do?

Thanks!!!!

XD