The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

suPHP, suExec and open_basedir oh my!

Discussion in 'Security' started by Evolve, Jan 24, 2014.

  1. Evolve

    Evolve Well-Known Member

    Joined:
    Jan 31, 2007
    Messages:
    47
    Likes Received:
    0
    Trophy Points:
    6
    I am at a loss. I have suPHP, suExec and open_basedir installed on my server and today I decided to use some PHP code from one account and put it on another account to work on. I discovered that the code on the new account had no problem executing the database connection code from the old account's root! I could even echo out the file contents from the other account and see the database passwords plain as day. Thank god I manage all of the sites on my server.

    My main concern is that I can execute the files in another accounts web root or anywhere just by knowing their username and the file name.
    Code:
    echo file_get_contents('/home/otherUser/file.php');
    Am I wrong in assuming that the purpose of suExec and suPHP is to lock down files to the account's user?

    While I can't find an explanation stating that I just assumed it was true. Here is something I found that sort of backs up my assumption:
    What am I missing here?

    Btw I realized recently that open_basedir doesn't work out of the box with suPHP and have found the thread where Tristan explains how to lock down php.ini files. I will do this after I figure out what's going on.


    I'm using PHP 5.4
     
  2. ThinIce

    ThinIce Well-Known Member

    Joined:
    Apr 27, 2006
    Messages:
    346
    Likes Received:
    7
    Trophy Points:
    18
    Location:
    Disillusioned in England
    cPanel Access Level:
    Root Administrator
    Potentially stupid question, but what are the permissions on the files in question? What version of PHP are you using to test? Many cms auto install their scripts config / sensitive files and leave them with 644 permissions, whereas they'd be better off as lower (i.e others cannot read). While settings like safe mode have come and gone, in the end it's the linux permissions that are the final protection.

    Things along the lines of this have come as a nasty shock in a variety of cases (for example the symlink issue where readable config files with 'normal' permissions can be harvested from the server)

    http://forums.cpanel.net/f185/solutions-handling-symlink-attacks-202242.html
     
  3. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,854
    Likes Received:
    675
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
    Hello :)

    I recommend checking the ownership values for the files in question. Check to see if they are owned by the appropriate user. Also, you mentioned installing suPHP. Did you ensure it was selected as the PHP handler in Web Host Manager(Home » Service Configuration » Configure PHP and suEXEC)?

    Thank you.
     
  4. Evolve

    Evolve Well-Known Member

    Joined:
    Jan 31, 2007
    Messages:
    47
    Likes Received:
    0
    Trophy Points:
    6
    The file I am executing in account1 is owned by account1 and has 644 permissions. If I change the permissions to 640 then it gets blocked from account2. Is this something I'm going to have to do to protect my files from other users??

    Yes suPHP is the selected handler:
    Default PHP Version (.php files) 5
    PHP 5 Handler suphp

    Apache suEXEC on
    Apache Ruid2 off

    I even re-saved the configuration and tried again.

    PHPInfo says: Server API: CGI/FastCGI

    Thanks
     
  5. ThinIce

    ThinIce Well-Known Member

    Joined:
    Apr 27, 2006
    Messages:
    346
    Likes Received:
    7
    Trophy Points:
    18
    Location:
    Disillusioned in England
    cPanel Access Level:
    Root Administrator
    If the files are sensitive and shouldn't be read, yes. Essentially whatever clever (or not so clever i.e. the now removed php safe mode) techniques are put in place to offer ersatz protection the file system permissions are the base of the thing. The history of protections for file access and execution on shared hosting is a bit of a roller coaster ride, these days it's de rigueur to deal with this at the OS level i.e. Technology

    If you're only maintaining a system for your own sites then likely you know which files are sensitive and can amend their permissions accordingly.
     
  6. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    942
    Likes Received:
    57
    Trophy Points:
    28
    cPanel Access Level:
    DataCenter Provider
    Your users home directories or public_html directories may have improper permissions. Make sure public_html is chowned to user:nobody and has permissions set to 750. Public_html directories themselves should not be 755 but I see them like this all the time. This should stop cross-account read on SuPHP systems, other than the symlink "hack"
     
  7. Evolve

    Evolve Well-Known Member

    Joined:
    Jan 31, 2007
    Messages:
    47
    Likes Received:
    0
    Trophy Points:
    6
    ThinIce: Yes I think I will take particular precautions with database files etc. from now on. I thought that if I had it in the root of the account, above public_html, it couldn't be accessible but that doesn't matter when accessing it from another account. I also thought suPHP would restrict usage to the account and that open_basedir was still working (which i know isn't working by default)

    quizknows: My public_html folders are g:nobody o:user permissions:750
    I'm actually accessing a file above public_html though. My cPanel account folder is: g:user o:user permission: 711

    Recently I had a corruption of the http.conf file when trying to block mod_security on a folder on an account. I used /scripts/rebuildhttpdconf to rebuilt it. Would that have had any negative effects?

    I'm seeing the following with each account:
    Code:
        <IfModule mod_suphp.c>
            suPHP_UserGroup user user
        </IfModule>
    and
    <IfModule !mod_disable_suexec.c>
            <IfModule !mod_ruid2.c>
                SuexecUserGroup user user
            </IfModule>
        </IfModule>
     
    #7 Evolve, Jan 24, 2014
    Last edited: Jan 24, 2014
  8. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    942
    Likes Received:
    57
    Trophy Points:
    28
    cPanel Access Level:
    DataCenter Provider
    sounds like directory perms are good then.

    /scripts/rebuildhttpdconf is a perfectly acceptable way to rebuild the apache config; you shouldn't edit httpd.conf directly on a cpanel system anyway. Rebuilding it that way will build it from the current settings and account data.
     
  9. Evolve

    Evolve Well-Known Member

    Joined:
    Jan 31, 2007
    Messages:
    47
    Likes Received:
    0
    Trophy Points:
    6
    So, I'm still stuck at square one.

    Should suPHP make it impossible for other users to execute your files?

    I see Tristan posted this in another thread:
    Why am I not getting these errors?

    quizknows: I actually wasn't modifying the httpd.conf directly; the corruption happened after running /scripts/ensure_vhost_includes/
     
    #9 Evolve, Jan 25, 2014
    Last edited: Jan 25, 2014
  10. ThinIce

    ThinIce Well-Known Member

    Joined:
    Apr 27, 2006
    Messages:
    346
    Likes Received:
    7
    Trophy Points:
    18
    Location:
    Disillusioned in England
    cPanel Access Level:
    Root Administrator
    suPHP doesn't make it impossible for other's to execute your files. suPHP is an interpreter and what *it* will execute can be configured (outside file permissions). It might be worthing taking a look at EasyApache: PHP Request Handling The defaults in /opt/suphp/etc/suphp.conf are reasonable, but can be tightened a little.

    This said, I'm unsure if that particular setting would make any difference to the function you mention in your original post, I'd imagine it may influence execution only
     
  11. cPanelPeter

    cPanelPeter Technical Analyst III
    Staff Member

    Joined:
    Sep 23, 2013
    Messages:
    569
    Likes Received:
    15
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    Twitter:
    Hello,

    Feel free to open a support ticket on this using the link in my signature. One of our analysts will be happy to look into this for you. Once you've opened a ticket, please post the ticket number in this thread so that we can update it accordingly.
     
  12. Evolve

    Evolve Well-Known Member

    Joined:
    Jan 31, 2007
    Messages:
    47
    Likes Received:
    0
    Trophy Points:
    6
    Ticket #4491249

    Thanks!
     
  13. cPanelPeter

    cPanelPeter Technical Analyst III
    Staff Member

    Joined:
    Sep 23, 2013
    Messages:
    569
    Likes Received:
    15
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    Twitter:
    Hello,

    To update this thread, there was some confusion on how permissions are inherited, but as a result there was also a new feature request created to assist with tightening permissions. The request is here and needs some more votes :)
     
  14. Evolve

    Evolve Well-Known Member

    Joined:
    Jan 31, 2007
    Messages:
    47
    Likes Received:
    0
    Trophy Points:
    6
    You beat me to it Peter!

    My thanks goes out to the cPanel staff helping me clarify what was going on.

    I'm not sure inheritance would be the right word.. maybe traversal? I got corrected for using inheritance by one of your staff :p

    I made the mistake of assuming suExec was some complex system that protected all of my folders automatically, regardless of location, by allowing only the user to access them; I didn't realize I had to take extra steps to change permissions on folders above the public_html folder to protect them from eavesdropping.

    I look forward to David Nielson's feature request getting some traction. I think it would help people out by adding one more layer of protection in that they may be oblivious to.
     
  15. ThinIce

    ThinIce Well-Known Member

    Joined:
    Apr 27, 2006
    Messages:
    346
    Likes Received:
    7
    Trophy Points:
    18
    Location:
    Disillusioned in England
    cPanel Access Level:
    Root Administrator
    My support added to this one
     
  16. georgeb

    georgeb Well-Known Member

    Joined:
    May 23, 2010
    Messages:
    48
    Likes Received:
    1
    Trophy Points:
    8
    Location:
    Montreal, QC, Canada
    cPanel Access Level:
    Root Administrator
    "open_basedir" is working with no problems. In my case I did this:
    - php.ini for each account, protected (only root access to those files, I can customize this by user needs);
    - for each account newly created a php.ini file will be generated automatically at account creation, with the open_basedir customized by username and username directory, so no access "out of the box";

    It is not complicated....


    Regards
     
    #16 georgeb, Feb 1, 2014
    Last edited: Feb 1, 2014
  17. stelian

    stelian Registered

    Joined:
    Aug 5, 2010
    Messages:
    3
    Likes Received:
    0
    Trophy Points:
    1
    Hello,

    I have a similar situation where error_get_last() print this:

    Code:
    Array
    (
        [type] => 2
        [message] => file_exists(): [B]open_basedir restriction in effect.[/B] File(/home/[B]user1[/B]/public_html/cache/lang/lang.php) [B]is not within the allowed path[/B](s): (/home/romanian/public_html/ewcms/ewcms_cache/lang:/home2/statisti/public_html)
        [file] => /home2/[B]user2[/B]/public_html/includes/libraries/cache.php
        [line] => 59
    )
    I have PHP running as suphp and suexex = On.
    /home2/user2/public_html/php.ini looks like this
    Code:
    open_basedir = "/home/USER1/public_html/cache/lang:/home2/user2/public_html"
    but it looks like "/home/USER1/public_html/cache/lang" is ignored.

    Basically I want that PHP running as user2 to modify some files on user1 homedir. I can't switch to DSO.
    Is there any way I could achieve what I want?

    Please help!
     
  18. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    942
    Likes Received:
    57
    Trophy Points:
    28
    cPanel Access Level:
    DataCenter Provider
    Is there any way to? Probably. Is it a good idea at all? No. Not at all. Assuming you're using SuPHP instead of DSO you'd have to loosen the security provided by SuPHP, likely disable symlink protection if you have any, and loosen file permissions.

    Find another way to do what you need to do without allowing cross-account access for web applications. From a security standpoint, what you're asking to do is a horrible idea (sorry, not trying to be personally offensive, it just is a terrible idea).
     
  19. stelian

    stelian Registered

    Joined:
    Aug 5, 2010
    Messages:
    3
    Likes Received:
    0
    Trophy Points:
    1
    Thank you @quizknows

    You are right, but that's a "horrible" application. I ended up setting a cronjob that synchronize 2 folders than chown on them. This way both users have their own copy and there is no need to mess with permissions.

    Best regards!
     
  20. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    942
    Likes Received:
    57
    Trophy Points:
    28
    cPanel Access Level:
    DataCenter Provider
    This sounds like a much better solution :) Glad you were able to get it figured out. Cheers.
     
Loading...

Share This Page