Pitfalls after rebuild and switching PHP from DSO to suPHP

[santrix]

For reasons of my own naivity when starting out, I still have a VPS server which is running PHP 5 as DSO - which hosts a number of accounts.

I was going to rebuild apache with the suPHP mod, so I can then run PHP as suPHP/CGI...

While I can go through all the accounts changing the owner/groups from nobody to the user account names for files/directories that have been created by PHP... I'm not sure what the impact might be on the .htaccess files...

The only things which exist in the .htaccess files are stuff like:

Options All -Indexes
DirectoryIndex index.php index.htm
RewriteEngine On
RewriteBase /
RewriteCond
RewriteRule
RedirectMatch
ErrorDocument

Is any of this going to stop working? I'm not terribly well read on the kinds of things which should be moved from .htaccess to local php.ini files, or indeed MUST be moved in order to work properly when running under suPHP.

Any advice? Thanks.

[santrix]

Thanks Mike... That's useful.

While I'm looking through easyapache... are the following advasible?

Fastcgi - enables mod FCGID

Force CGI Redirect

Sorry to sound lame, I've not used these before and haven't yet found a useful high level overview of their impact.

I found this http://uk3.php.net/manual/en/securit...in.attacks.php which is making me wonder if running under suPHP (which implies CGI, doesn't it?) is actually such a good idea, unless I do some other nailing down, which I am still trying to figure out.

[mtindor]

Options All -Indexes
DirectoryIndex index.php index.htm
RewriteEngine On
RewriteBase /
RewriteCond
RewriteRule
RedirectMatch
ErrorDocument

None of those should stop working. Things like php_values, if you had them in a .htaccess file, would stop working.

In a non-suPHP environ, you could put the php values in a .htaccess file and they would recursively take effect.

In an suPHP environ, your customers would have to create their own php.ini file and would have to put that same file in every directory that their php application may use in order for it to work. And, of course, that's only if you have your system configured to allow users to have their own php.ini file.

Mike

[cPanelDon]

mtindor is correct. Related entries to look for in .htaccess files includes those starting with "php_" such as php_flag and php_value.

FastCGI may not be something preferable to try unless you have an experienced Systems Administrator to configure it.

Force CGI Redirect may be safe to enable if it's needed; here is a related documentation link explaining it in more detail:
PHP: Case 2: using --enable-force-cgi-redirect - Manual

If a customized php option is needed when using SuPHP, the setting should be defined within a custom php.ini file in the directory of the PHP script that requires the change. Please note that the syntax for the PHP entries in an .htaccess file versus a php.ini file are different; I recommend checking the PHP documentation if needed.

Reference:
PHP: List of php.ini directives - Manual

[santrix]

Thanks for that... one other question about the impact of moving to suPHP (which we've now completed)...

We had an SMF forum hacked a while ago... because, at the time, the web user was nobody, they were unable to overwrite the .htaccess files, as they were put there by the hosting user account...

Aren't htaccess files more vulnerable now that apache is running in the the same context as the hosting account (and therefore has the priveledge to overwrite the htaccess files?)

Steve

[cPanelDavidG]

This discussion seems to be discussing the security implications of using SuPHP. As a result, I have moved this to the Security forum.

[Spiral]

I have discussed this many times but here is a recap for late comers ...

There are a number of differences between DSO (Apache Module) and SuPHP based PHP and you must address these items when converting an existing system to SuPHP else you may have some sites generating "Error 500":

1. PHP scripts MUST have the account owner as the owner of the script
and cannot be user "nobody" or some other user as the script owner.

2. PHP scripts CANNOT be located in a folder with writable global
permissions which means no "666" or "777" folders.

3. Per #2, the PHP scripts themselves cannot be globally writable

NOTE: Global writable is not only not permitted under SuPHP but also not required either. You can ignore script instructions telling you to set 777 permissions when running under SuPHP

4. The commands "php_flag" and "php_admin" used to override
PHP configuration settings under DSO based php do not exist under
SuPHP and those commands are invalid in .htaccess and httpd.conf.

I have made a simple script available to those running Linux based Cpanel servers to help correct the above 4 items that you can run AFTER you run EasyApache and convert to SuPHP ...

# cd /usr/local/src
# wget http://www.myserverexpert.com/build/dso2su.sh
# chmod 0700 ./dso2su.sh
# ./dso2su.sh
# service httpd restart

This script is not designed to convert your system to SuPHP but rather to fix the Error 500 and compatibility issues you will need to fix on existing sites after you have converted your system to SuPHP and will examine all sites on your server and apply fixes for those 4 items I just listed.

After running this script, you will want to check your logs in /var/log as notes will be left on which .htaccess files you will want to review to see if the user will possibly need a custom PHP configuration (PHP.INI) for any settting overrides they may have had previously (php_flag / php_value).
When the script is run, it just disables those commands in .htaccess by commenting out the invalid commands. You will need to follow up to determine if the users owning those accounts still need the previous PHP setting overrides they had under DSO based PHP.

While I'm looking through easyapache... are the following advisable?

Fastcgi - enables mod FCGID

Force CGI Redirect

No, do not select "FastCGI" or "eAccelerator" when setting up SuPHP in EasyApache!

(Neither of these will function with SuPHP -- However, SuPHP's DSO component handles things well on it's own)

Regarding "Force CGI Redirect", you you can select that option and I would in fact recommend it.

[goodmove]

............

No, do not select "FastCGI" or "eAccelerator" when setting up SuPHP in EasyApache!

(Neither of these will function with SuPHP)

...........

Not strictly true. You could set up SuPHP system-wide and FastCGI per-user as needed.

[Spiral]

Not strictly true. You could set up SuPHP system-wide and FastCGI per-user as needed.

Actually you are both wrong and right at the same time, goodmove!

The post to which you are responding was posted last October and at the time it was posted, there were a bug that caused problems if both FastCGI and SuPHP were enabled at the same time.

This issue has since been resolved and is no longer a problem anymore.

However, regarding the other item 'eAccelerator' --- still leave that one OFF

[santrix]

Just a note about the dso2su.sh script you kindly made available...

In the section that fixes BAD permissions on php scripts... the line that reads

     for PMD in 666 777; do
       /usr/bin/find ${CPHOME} -type f -perm ${PMD} -name '*.php' >> ${TFILE} 2> /dev/null
     done

Would this be better as just

       /usr/bin/find ${CPHOME} -type f -perm /137 -name '*.php' >> ${TFILE} 2> /dev/null

This just finds anything with the execute bit set or the write bit set for Group, or any rights at all for the World user... Tell me if I get a gold star...

[Spiral]

Nope. The original first version of that script was done that way and changed to explicit "777" and "666" because there are a few instances where users actually needed those bits set but weren't using those specific permission patterns so to address those and minimize false matches, later versions of the script were changed to name the permissions directly.

[santrix]

Please forgive my dumbness, but why, under suPHP, would you want

executable for the owner
executable or writable by the group
any permissions for nobody directly

I'm sure there are some devious reasons, but humour me

[cpanelkenneth]

Please be aware that the script Spiral provides ( Pitfalls after rebuild and switching PHP from DSO to suPHP ) allows user's to take over arbitrary files on the same file system as /home. This is due to this step in his script:

/bin/chown -R ${CPUSER}:${CPUSER} -- ${CPHOME}/*

which is being performed as the root user in all likelihood. The following example illustrates the danger.

root@tilly [~]# su - homer
-bash-3.2$ ls -la /etc/shadow
-rw------- 1 root root 905013 Mar 24 14:48 /etc/shadow
-bash-3.2$ ln /etc/shadow public_html/my_stuff.php
-bash-3.2$ ls -l public_html/my_stuff.php 
-rw------- 2 root root 905013 Mar 24 14:48 public_html/my_stuff.php
-bash-3.2$ logout
root@tilly [~]# ls -l /etc/shadow 
-rw------- 2 root root 905013 Mar 24 14:48 /etc/shadow
root@tilly [~]# ls -l /home/homer/public_html/my_stuff.php 
-rw------- 2 root root 905013 Mar 24 14:48 /home/homer/public_html/my_stuff.php
root@tilly [~]# chown -R homer:homer /home/homer/public_html/*
root@tilly [~]# ls -l /home/homer/public_html/my_stuff.php 
-rw------- 2 homer homer 905013 Mar 24 14:48 /home/homer/public_html/my_stuff.php
root@tilly [~]# ls -l /etc/shadow 
-rw------- 2 homer homer 905013 Mar 24 14:48 /etc/shadow

Recursively chowning, as root, directories under a user's control is fraught with peril.

Spiral was notified of this, and other, vulnerabilities in his script some months ago ( http://forums.cpanel.net/f5/scripts-...em-132985.html ) but has failed to address them.

[santrix]

I appreciate your proof of concept, but my understanding of the script is that the context in which the line

/bin/chown -R ${CPUSER}:${CPUSER} -- ${CPHOME}

appears, means that $CPUSER and $CPHOME can't ever be "root" or "/root" because it is encased within a while loop that starts:

/bin/ls -- /var/cpanel/users | /bin/grep -v "\`\|\.\|cpanel\|root\|mysql\|nobody" | while read CPUSER; do

So, I can't see how it is possible for this script to expose this exploit. However, it's late on Friday and I have been wrong before... often...

[cPanelDavidG]

So, I can't see how it is possible for this script to expose this exploit. However, it's late on Friday and I have been wrong before... often...

Are you familiar with what the ln command does? I ask because that may be the cause of some misunderstanding about why this is a vulnerability.

FWIW, I've often misread ln as ls in similar reports, especially on Fridays .