Perl symlink - huge security issue

[EEssam]

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.

[brianoz]

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.

[sparek-3]

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.

[cPanelDavidG]

The equivalent of SuPHP for Perl is SuExec.

[brianoz]

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

[chirpy]

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.

[UBERHOST]

Another good reason to always use suPHP.

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.

[chirpy]

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.

[UBERHOST]

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.

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!

[bluestar]

The equivalent of SuPHP for Perl is SuExec.

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:

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

Code I used

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

[cpanelstephen]

Code I used

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

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:

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 [~]#

[cpanelstephen]

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.

[sparek-3]

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.

[bluestar]

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

[sparek-3]

What file are you symlinking?

What are the permissions on this file?