1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Pitfalls after rebuild and switching PHP from DSO to suPHP

Discussion in 'Security' started by santrix, Oct 16, 2009.

Thread Status:
Not open for further replies.
  1. santrix

    santrix Member

    Joined:
    Nov 30, 2008
    Messages:
    211
    Likes Received:
    2
    Trophy Points:
    18
    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. santrix

    santrix Member

    Joined:
    Nov 30, 2008
    Messages:
    211
    Likes Received:
    2
    Trophy Points:
    18
    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/security.cgi-bin.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.
     
    #2 santrix, Oct 16, 2009
    Last edited: Oct 16, 2009
  3. mtindor

    mtindor Active Member

    Joined:
    Sep 14, 2004
    Messages:
    1,182
    Likes Received:
    8
    Trophy Points:
    38
    Location:
    inside a catfish
    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. cPanelDon

    cPanelDon cPanel Quality Assurance Analyst
    Staff Member

    Joined:
    Nov 5, 2008
    Messages:
    2,558
    Likes Received:
    6
    Trophy Points:
    38
    Location:
    Houston, Texas, U.S.A.
    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. santrix

    santrix Member

    Joined:
    Nov 30, 2008
    Messages:
    211
    Likes Received:
    2
    Trophy Points:
    18
    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. cPanelDavidG

    cPanelDavidG Technical Product Specialist

    Joined:
    Nov 29, 2006
    Messages:
    11,288
    Likes Received:
    6
    Trophy Points:
    38
    Location:
    Houston, TX
    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. Spiral

    Spiral BANNED

    Joined:
    Jun 24, 2005
    Messages:
    2,023
    Likes Received:
    7
    Trophy Points:
    0
    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.

    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. ;)
     
    #7 Spiral, Oct 20, 2009
    Last edited: Oct 20, 2009
  8. goodmove

    goodmove Member

    Joined:
    May 12, 2003
    Messages:
    633
    Likes Received:
    0
    Trophy Points:
    16
    Not strictly true. You could set up SuPHP system-wide and FastCGI per-user as needed.
     
  9. Spiral

    Spiral BANNED

    Joined:
    Jun 24, 2005
    Messages:
    2,023
    Likes Received:
    7
    Trophy Points:
    0
    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. santrix

    santrix Member

    Joined:
    Nov 30, 2008
    Messages:
    211
    Likes Received:
    2
    Trophy Points:
    18
    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. Spiral

    Spiral BANNED

    Joined:
    Jun 24, 2005
    Messages:
    2,023
    Likes Received:
    7
    Trophy Points:
    0
    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. santrix

    santrix Member

    Joined:
    Nov 30, 2008
    Messages:
    211
    Likes Received:
    2
    Trophy Points:
    18
    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 :D
     
  13. cPanelKenneth

    cPanelKenneth cPanel Development
    Staff Member

    Joined:
    Apr 7, 2006
    Messages:
    4,318
    Likes Received:
    7
    Trophy Points:
    38
    Please be aware that the script Spiral provides ( http://forums.cpanel.net/f185/pitfalls-after-rebuild-switching-php-dso-suphp-135109.html#post583769 ) 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-chownpublichtmls-problem-132985.html ) but has failed to address them.
     
  14. santrix

    santrix Member

    Joined:
    Nov 30, 2008
    Messages:
    211
    Likes Received:
    2
    Trophy Points:
    18
    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... :p
     
  15. cPanelDavidG

    cPanelDavidG Technical Product Specialist

    Joined:
    Nov 29, 2006
    Messages:
    11,288
    Likes Received:
    6
    Trophy Points:
    38
    Location:
    Houston, TX
    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 ;).
     
  16. cPanelKenneth

    cPanelKenneth cPanel Development
    Staff Member

    Joined:
    Apr 7, 2006
    Messages:
    4,318
    Likes Received:
    7
    Trophy Points:
    38
    Because
    Code:
    /bin/chown -R ${CPUSER}:${CPUSER} -- ${CPHOME}
    is the same as

    Code:
    chown -R homer:homer /home/homer/public_html/*
    
    in my proof of concept. Notice that the command is not relying upon sending root:root or operating on /root, the flaw is in blindly chowning files as root.

    All that this line:

    Code:
    /bin/ls -- /var/cpanel/users | /bin/grep -v "\`\|\.\|cpanel\|root\|mysql\|nobody" | while read CPUSER; do
    
    does is ensure the chown step doesn't do this:

    Code:
    chown -R root:root /home/homer/public_html/*
    
    which would be harmful in another manner.

    So, let's do a step-by-step commentary on a few lines from this script:

    Code:
    /bin/ls -- /var/cpanel/users | /bin/grep -v "\`\|\.\|system\|cpanel\|root\|mysql\|nobody" | while read CPUSER; do
    
    Get a list of cPanel users, filtering out root, system, cpanel, mysql, nobody, ` and . Iterate over this list.

    Code:
       CPHOME="$(/bin/grep "^${CPUSER}:" /etc/passwd | cut -d':' -f6)/public_html"
    
    Grab the location of the home directory for the user. Set the bash variable to /home/user/public_html

    Code:
       dialog --keep-window --title "Checking ${CPHOME}" --infobox "\n\n Updating ${CPUSER}'s account ..." 10 50
       sleep ${DELAY}   # Slow things down so you can see dialog message
       echo "Checking ${CPHOME} ... "
    
    Provide some feedback

    Code:
       if [ -d "${CPHOME}" ]; then
    
    Ensure /home/user/public_html is directory

    Code:
         echo "Setting global ownership in ${CPHOME} to ${CPUSER} ..."
    
    Feedback

    Code:
         /bin/chown -R ${CPUSER}:${CPUSER} -- ${CPHOME}/*
    
    Blindly change ownership of everything in /home/user/public_html to user:user. This is the problem line illustrated in my proof of concept.

    If you doubt it, you are free to perform your own analysis and tests. I'm simply providing a warning and information on the danger of executing this script without performing due diligence.
     
  17. santrix

    santrix Member

    Joined:
    Nov 30, 2008
    Messages:
    211
    Likes Received:
    2
    Trophy Points:
    18
    Ah! Duh!

    Something learnt there...

    by creating a hard link to the file /etc/shadow owned by root, you have created a virtual php file with ownership set to root...

    Now, running the command

    Code:
    /bin/chown -R ${CPUSER}:${CPUSER} -- ${CPHOME}
    AS ROOT... this means you are forcing the virtual php file, ergo the original file to become owned by the mere mortal user... Arrgghh!! now I see.

    So, the safest way to run this script would actually be:

    Code:
    /usr/bin/sudo -u homer chown -R ${CPUSER}:${CPUSER} -- ${CPHOME}
    Although not knowing sudo usage too well, I expect that may need refining, but you get the gist... i.e. if the command was run under the context of the user account being processed, then it wouldn't be able to overwrite root's ownership of the original /etc/shadow file?
     
  18. cPanelKenneth

    cPanelKenneth cPanel Development
    Staff Member

    Joined:
    Apr 7, 2006
    Messages:
    4,318
    Likes Received:
    7
    Trophy Points:
    38
    This:

    Code:
    /usr/bin/sudo -u homer chown -R ${CPUSER}:${CPUSER} -- ${CPHOME}
    won't accomplish one of your goals which is to change homer:nobody or nobody:nobody to homer:homer. Only the root user can change ownership of a file.

    One solution I'm aware of to prevent this ( and likely not the only solution ) is to:

    1. Lock the directory so the user cannot access it
    2. For each file in the directory:
    a. verify the file is not a hard link to another file
    b. if the file is not a hard link, change ownership
    c. if the file is a hard link, skip processing this file
    3. After all files in the directory are processed, unlock the directory

    By locking the directory, I mean an action:

    Code:
    chown root:root directory_name
    chmod 0700
    
    And then reversing the above for step 3.

    The reason for locking the directory is to prevent a race condition between verifying a file is not a hard link to another file and the ownership change. Since the check and the change are two separate actions a malicious user could change the file between the two actions.

    Some information on this ( hopefully not sleep inducing ) is found here: Avoid Race Conditions
     
    Infopro likes this.
  19. santrix

    santrix Member

    Joined:
    Nov 30, 2008
    Messages:
    211
    Likes Received:
    2
    Trophy Points:
    18
    Yeah, I figured this out just after I wrote my reply and tested it in a shell...

    I went and ran the script on a new server (eeek!)... I've just written another script to check for files belonging to users account that exist outside of their home directories... only a few (trusted) users on this box, and luckily nothing suspicious... lesson well and truly learnt!

    Now... it's friday... it's 19:20hrs local, and I must be one sad git for being sat here and not consuming beer... Have a good weekend! :D
     
  20. Spiral

    Spiral BANNED

    Joined:
    Jun 24, 2005
    Messages:
    2,023
    Likes Received:
    7
    Trophy Points:
    0
    Under normal circumstances you don't need executable anything but there are some special exceptions and unusual configurations that you must account for as well when writing a script to be used by everyone on many different types of servers under different configurations and more specifically with different software applications including a couple specific ones I know to be a bit screwy in their design.

    Under normal circumstances barring any strangeness like that, the following is the permissions you would want normally (SuPHP/FCGI):

    755 All Folders
    600 PHP Scripts (most all PHP scripts)
    400 PHP Scripts (those that don't like being writable *RARE*)
    755 CGI Scripts (*.pl, *.pm, *py, *.e, *.cgi)
    644 All Other Files (Images, Templates, HTML, Text, Etc)

    No! And for your information Apache is **NOT** running as the users but rather instead is still running as "nobody" same as always!

    Your scripts however are being executed under your username which is actually better for you because you won't run into that situation like you just mentioned where you had difficulty editing the .htaccess because the file was owned by user "nobody".

    If you want to take things a step above and beyond, you can set the permission of owner on the .htaccess to "4" which disables write access to yourself and put in a deny block for .htaccess inside the .htaccess which is still read just fine by Apache but won't allow visitor direct access
     
Thread Status:
Not open for further replies.

Share This Page