Perl symlink - huge security issue

EEssam

Member
Feb 20, 2008
10
0
51
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

Well-Known Member
Mar 13, 2004
1,146
7
168
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.
 

sparek-3

Well-Known Member
Aug 10, 2002
1,983
218
343
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.
 

brianoz

Well-Known Member
Mar 13, 2004
1,146
7
168
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
 
Last edited:

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,465
30
473
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.
 

UBERHOST

Well-Known Member
Jan 13, 2008
102
0
66
California, US
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

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,465
30
473
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.
 

UBERHOST

Well-Known Member
Jan 13, 2008
102
0
66
California, US
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

Registered
Mar 26, 2009
2
0
51
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:
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");
 

cPanelStephen

Active Member
Staff member
Aug 7, 2007
25
0
51
Code I used

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

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

cPanelStephen

Active Member
Staff member
Aug 7, 2007
25
0
51
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

Well-Known Member
Aug 10, 2002
1,983
218
343
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.
 

bluestar

Registered
Mar 26, 2009
2
0
51
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
 

Spiral

BANNED
Jun 24, 2005
2,020
8
193
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.
 

brianoz

Well-Known Member
Mar 13, 2004
1,146
7
168
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.