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.

Perl symlink - huge security issue

Discussion in 'Security' started by EEssam, Jun 30, 2008.

  1. EEssam

    EEssam Member

    Joined:
    Feb 20, 2008
    Messages:
    10
    Likes Received:
    0
    Trophy Points:
    1
    Hello,

    I'm running a cPanel shared hosting company... check what a user did to hack other users:

    #!/usr/bin/perl
    symlink ("/home/hackedperson/public_html/vb/includes/config.php","/home/hacker/public_html/rrr.txt.zip");

    How can we prevent this from happening?

    It's extremely important to fix this security hole because forum installation are being hacked almost everyday using this method.

    Your help would be greatly appreciated. Thanks.
     
  2. brianoz

    brianoz Well-Known Member

    Joined:
    Mar 13, 2004
    Messages:
    1,146
    Likes Received:
    6
    Trophy Points:
    38
    Location:
    Melbourne, Australia
    cPanel Access Level:
    Root Administrator
    This is a known class of hack, the solution to which is to use suPHP. With suPHP each user PHP process runs under a separate ownership partition.

    If you can't use suPHP, the solution is much harder - you have to secure PHP thoroughly, and use suhosin or similar.
     
  3. sparek-3

    sparek-3 Well-Known Member

    Joined:
    Aug 10, 2002
    Messages:
    1,383
    Likes Received:
    23
    Trophy Points:
    38
    cPanel Access Level:
    Root Administrator
    Add symlink to your list of disabled functions in your php.ini file.

    Edit: Nevermind, you're talking about perl not PHP. My bad. I don't have a solution for this.
     
  4. cPanelDavidG

    cPanelDavidG Technical Product Specialist

    Joined:
    Nov 29, 2006
    Messages:
    11,279
    Likes Received:
    8
    Trophy Points:
    38
    Location:
    Houston, TX
    cPanel Access Level:
    Root Administrator
    The equivalent of SuPHP for Perl is SuExec.
     
  5. brianoz

    brianoz Well-Known Member

    Joined:
    Mar 13, 2004
    Messages:
    1,146
    Likes Received:
    6
    Trophy Points:
    38
    Location:
    Melbourne, Australia
    cPanel Access Level:
    Root Administrator
    Actually there is quite a good solution; suexec will keep you safe, sorry for missing the Perl part, but it will work. The permissions on the user directories change so the sym link can be created but the user won't have permission on the path through to the file. There are other ways to read user files without suexec, this is only one example.

    The other thing that will help is that Apache has an option to not follow sym links; you can turn that on and it will help a little. It may be possible to switch it off, although there's an incantation to prevent that I beleive, perhaps someone will
     
    #5 brianoz, Jun 30, 2008
    Last edited: Jul 1, 2008
  6. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    suPHP is still relevant here, because PHP scripts will be running under the nobody user. If the PHP script in turn calls the perl script, it will run under that nobody user and create the symlink to any account that allows nobody write access (i.e. most accounts running PHP scripts). Another good reason to always use suPHP.
     
  7. UBERHOST

    UBERHOST Well-Known Member

    Joined:
    Jan 13, 2008
    Messages:
    102
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    California, US
    Yes, I quite agree that there are many good reasons to use suPHP, but I know that if we installed it on each and every one of our shared servers we'd lose too much business for it to be a feasible option, unfortunately.
     
  8. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    Which is always a problem. It's also a good reason to enable it when you commission a new server and before adding new clients to it. That way it effectively becomes invisible.

    Without it enabled you do simply have to accept that on a shared hosting server any client will have at least read (and often write) access to any other clients files and directories.
     
  9. UBERHOST

    UBERHOST Well-Known Member

    Joined:
    Jan 13, 2008
    Messages:
    102
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    California, US
    Yes, this is what we do. For the most part it is the clients running Dolphin, Clipshare (and other scripts employing outdated forms) that cannot run under suPHP. Pity!
     
  10. bluestar

    bluestar Registered

    Joined:
    Mar 26, 2009
    Messages:
    2
    Likes Received:
    0
    Trophy Points:
    1
    I disabled .pl, .cgi outside cgi-bin folder in the apache configuration file. I have enabled SuEXEC in apache and still this is working from inside user cgi-bin folder. Is there any work around?

    Logs:
    Code:
    [2009-03-26 06:22:48]: uid: (32076/username) gid: (32079/username) cmd: filename.pl
    
    Code I used

    Code:
    #!/usr/bin/perl
    symlink ("/home/user1/public_html/testbilling/configuration.php","/home/user2/public_html/testfile.txt");
    
     
  11. cPanelStephen

    cPanelStephen Active Member
    Staff Member

    Joined:
    Aug 7, 2007
    Messages:
    25
    Likes Received:
    0
    Trophy Points:
    1
    This is simply a matter of permissions. A user can create a symbolic link to any file or directory they want, but unless they have the appropriate permissions to access that file, it will remain inaccessible to them:

    Code:
    root@host [~]# ls -lh /usr/local/apache/conf/httpd.conf
    -rw------- 1 root wheel 119K Mar 26 12:03 /usr/local/apache/conf/httpd.conf
    root@freshness [~]# su - somebody
    somebody@somebody.com [~]# perl -e 'symlink q{/usr/local/apache/conf/httpd.conf}, q{some_random_file}';
    somebody@somebody.com [~]# ls -l some_random_file 
    lrwxrwxrwx 1 somebody somebody 33 Mar 26 12:04 some_random_file -> /usr/local/apache/conf/httpd.conf
    somebody@somebody.com [~]# cat some_random_file 
    cat: some_random_file: Permission denied
    somebody@somebody.com [~]# 
    
     
  12. cPanelStephen

    cPanelStephen Active Member
    Staff Member

    Joined:
    Aug 7, 2007
    Messages:
    25
    Likes Received:
    0
    Trophy Points:
    1
    I should also note that having both suPHP and suEXEC enabled allows the applications to generate configuration files as the users themselves, rather than the user 'nobody'.

    Taking this measure prevents other users from accessing those files, since they will not have the appropriate permissions unless the file is world readable. While other users may be able to create a symbolic link to that location in the file system, it will still remain completely inaccessible to them.
     
  13. sparek-3

    sparek-3 Well-Known Member

    Joined:
    Aug 10, 2002
    Messages:
    1,383
    Likes Received:
    23
    Trophy Points:
    38
    cPanel Access Level:
    Root Administrator
    This is why ideally, everyone would run suexec and suPHP (or some PHP suexec wrapper) and PHP configuration files, such as Wordpress database configuration included files, should be set with a permission of 0600, meaning that only the owner of the file would have read/write permission. This would still work for the user's website, but other accounts on the shared hosting server would not be able to read the configuration.

    The issue would become moot if the owner of the file let his or her Wordpress installation become outdated and vulnerable to attack. Hackers may then be able to hack into the user's Wordpress installation and retrieve the database login credentials. Still, this is a problem that the owner of the account has nobody else to blame but themselves.

    Rarely do you see script installation instructions that tell you to set the permissions on the configuration file to 0600 because this won't work in a non-suphp environment and they cannot know if you have suphp enabled on your server or not.

    This would apply to any script you install, not just Wordpress. I just used Wordpress here as an example.
     
  14. bluestar

    bluestar Registered

    Joined:
    Mar 26, 2009
    Messages:
    2
    Likes Received:
    0
    Trophy Points:
    1
    In an suexec environment the symlinked file cannot be read from cpanel
    filemanager, cannot download using ftp, cannot read from jailshell. Only way is through browser using the FollowSymLinks set in .htaccess. This will work and the file contents will be displayed in browser.

    I my example we can read the source file contents using the url below.

    http://domain.com/testfile.txt
     
  15. sparek-3

    sparek-3 Well-Known Member

    Joined:
    Aug 10, 2002
    Messages:
    1,383
    Likes Received:
    23
    Trophy Points:
    38
    cPanel Access Level:
    Root Administrator
    What file are you symlinking?

    What are the permissions on this file?
     
  16. Spiral

    Spiral BANNED

    Joined:
    Jun 24, 2005
    Messages:
    2,023
    Likes Received:
    7
    Trophy Points:
    0
    Aside from the above tips which were all very good, I would also take
    a close look at the permissions of a number of your standard operating
    system utilities and commands and set the permissions to be
    executable by root only for those that aren't normally needed by
    anyone outside of root.

    Nearly all the scripting languages have shell capabilities which everyone
    around here should already know. However, what might be lessor known
    is that many of the built in functions of many of the scripting languages
    like Perl and PHP still make system calls to standard operating system
    commands when using many of the internal functions so while you
    can disable shell commands in a lot of languages, there is still the problem
    that users might still be able to run commands they otherwise should not.

    In regard to this thread specifically ...
    Code:
    chown root:root /usr/ln
    chmod 0750 /usr/ln
    
    The same can be applied to many, many other commands.

    I typically lock down chmod and chown commands themselves as well
    for the exact same reasons since nobody other than root should be
    changing permissions on my servers anyway.

    Stop and think about what commands you and your non-root
    server processes use (if any) and then think about what your
    web hosting clients should be using and that will help you figure
    out what commands should probably be locked down.

    For commands you are not certain, you can easily write a logging
    wrapper script and replace the command and then monitor the
    log file to see how the command is used and that will help you
    determine how you should set the permissions.
    Code:
    mv /usr/bin/ln /usr/bin/spleen
    
    create a new 'ln' command with 0755 permissions ...
    Code:
    #!/bin/bash
    IFS="$"
    
    echo "$(date) LN executed with \'${*}\' options" >> /var/log/ln.log
    /usr/bin/spleen ${*}
    
    (Just a quick rough write to illustrate the basic concept only)

    You would be surprised how many hack attempts have been foiled trying
    various known and unknown exploits just simply because their scripts
    couldn't call the simplest of functions they had assumed were accessible.
     
  17. brianoz

    brianoz Well-Known Member

    Joined:
    Mar 13, 2004
    Messages:
    1,146
    Likes Received:
    6
    Trophy Points:
    38
    Location:
    Melbourne, Australia
    cPanel Access Level:
    Root Administrator
    Code:
    #!/bin/bash
    IFS=" "
    
    echo "$(date) LN executed with \'${*}\' options" >> /var/log/ln.log
    ps -fp$PPID >> /var/log/ln.log
    /usr/bin/spleen ${*}
    
    The above code needed two changes; one so you could tell where it was called from (ps -fp), and the IFS setting would have caused problems (did you intend a field sep of '$'?).

    Spiral's advice is very wise. I've run with wget and curl disabled for years, you'd be amazed how much it stops. We also disable a few other things such as cc/gcc. Removing these permissions is one of the simplest and most effective things you can do to make a system more secure.
     
Loading...

Share This Page