Page 1 of 2 12 LastLast
Results 1 to 15 of 22

Thread: Pitfalls after rebuild and switching PHP from DSO to suPHP

  1. #1
    Registered Member
    Join Date
    Nov 2008
    Posts
    211

    Default Pitfalls after rebuild and switching PHP from DSO to suPHP

    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.

  2. #2
    Registered Member
    Join Date
    Nov 2008
    Posts
    211

    Default

    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.
    Last edited by santrix; 10-16-2009 at 02:45 PM.

  3. #3
    Registered Member
    Join Date
    Sep 2004
    Location
    inside a catfish
    Posts
    1,152
    cPanel/WHM Access Level

    Root Administrator

    Default

    Quote Originally Posted by santrix View Post
    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

  4. #4
    cPanel Quality Assurance Analyst cPanelDon's Avatar
    Join Date
    Nov 2008
    Location
    Houston, Texas, U.S.A.
    Posts
    2,554
    cPanel/WHM Access Level

    DataCenter Provider

    Lightbulb

    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

  5. #5
    Registered Member
    Join Date
    Nov 2008
    Posts
    211

    Default

    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

  6. #6
    Technical Product Specialist cPanelDavidG's Avatar
    Join Date
    Nov 2006
    Location
    Houston, TX
    Posts
    11,295
    cPanel/WHM Access Level

    Root Administrator

    Arrow Friendly Moderator Note

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

  7. #7
    BANNED
    Join Date
    Jun 2005
    Posts
    2,023

    Default

    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 ...

    Code:
    # 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.

    Quote Originally Posted by santrix
    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.
    Last edited by Spiral; 10-20-2009 at 11:27 PM.

  8. #8
    Registered Member
    Join Date
    May 2003
    Posts
    632

    Default

    Quote Originally Posted by Spiral View Post
    ............

    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.

  9. #9
    BANNED
    Join Date
    Jun 2005
    Posts
    2,023

    Default

    Quote Originally Posted by goodmove View Post
    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

  10. #10
    Registered Member
    Join Date
    Nov 2008
    Posts
    211

    Red face

    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

    Code:
         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

    Code:
           /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...

  11. #11
    BANNED
    Join Date
    Jun 2005
    Posts
    2,023

    Default

    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.

  12. #12
    Registered Member
    Join Date
    Nov 2008
    Posts
    211

    Default

    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

  13. #13
    cPanel Development cPanelKenneth's Avatar
    Join Date
    Apr 2006
    Posts
    4,271
    cPanel/WHM Access Level

    Root Administrator

    Default

    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:

    Code:
    /bin/chown -R ${CPUSER}:${CPUSER} -- ${CPHOME}/*
    which is being performed as the root user in all likelihood. The following example illustrates the danger.

    Code:
    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.
    Kenneth
    Development
    cPanel, Inc.

  14. #14
    Registered Member
    Join Date
    Nov 2008
    Posts
    211

    Default

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

    Code:
    /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:

    Code:
    /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...

  15. #15
    Technical Product Specialist cPanelDavidG's Avatar
    Join Date
    Nov 2006
    Location
    Houston, TX
    Posts
    11,295
    cPanel/WHM Access Level

    Root Administrator

    Default

    Quote Originally Posted by santrix View Post
    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 .

Page 1 of 2 12 LastLast

Similar Threads

  1. Converting DSO to suPHP
    By ctrl in forum Optimization
    Replies: 4
    Last Post: 07-17-2012, 04:15 PM
  2. dso vs suphp vs fastcgi
    By Usmeee in forum Optimization
    Replies: 10
    Last Post: 09-05-2011, 07:08 PM
  3. Converting from PHP DSO to PHP suPHP + Suhosin
    By host4profit in forum Security
    Replies: 4
    Last Post: 03-03-2011, 10:58 PM
  4. suPHP + dso module
    By geolaw999 in forum Optimization
    Replies: 0
    Last Post: 07-26-2010, 12:52 PM
  5. (98)Address already in use when switching PHP from CGI to DSO.
    By afdg in forum cPanel & WHM Discussions
    Replies: 3
    Last Post: 09-15-2008, 03:47 AM
bargain