Solutions for handling symlink attacks

Status
Not open for further replies.

stgeorge

Member
Jul 20, 2012
6
0
1
cPanel Access Level
Root Administrator
Being a New Admin to WHM, I am Shocked that cPanel has not found a Solution for this or at least provided a Guide on how to prevent Symbolic Link Hacking in a Shared Hosting environment.

This is the eleventh page with no Actual Definitive Information on how to Stop the Hacking.

Yet the Thread on this Hack has been around for a Year.

Has anyone actually Solved this?
 

JeffP.

Well-Known Member
Sep 28, 2010
164
15
68
CloudLinux has: SecureLinks

CloudLinux provides a better solution for the problem, that makes sure that any static file served by Apache for the VirtualHost will be owned by same user as specified in SuexecUserGroup directive for that VirtualHost.
This completely prevents the potential for such attacks. The solution doesn't suffer from race conditions. It is very efficient, with much lower overhead then SymLinksIfOwnerMatch.
and there are some 3rd party patches provided in this thread that you may be interested in as well.
 

nospa

Well-Known Member
Apr 23, 2012
110
0
66
cPanel Access Level
Reseller Owner
SecureLinks is something that we need to pay for. We pay already for cPanel, quite high price (almost $30 a month for 1 server), so I think we can expect implementing some patches into Easyapache. Not every WHM / cPanel admin is familar with this thread, so cPanel should be a step before all of us, and provide such extra help as module in Easyapache.
 

brianoz

Well-Known Member
Mar 13, 2004
1,146
7
168
Melbourne, Australia
cPanel Access Level
Root Administrator
Jeff,

I'm afraid I agree in that my feeling is that cPanel is letting down the community by not providing a fix. At the very least, the fact that this major security hole has been left unpatched by cPanel could result in perpetuating the myth that cPanel is insecure.

Make no mistake - this is a hole that allows nearly every site on a server to be hacked through database connections; it really couldn't be any more serious. Additionally, this has been around for long enough unpatched that it will be getting into the kits that script kiddies run. This will only cause more and more pain for all, including cPanel support, if left unpatched.

To top this off, there's been recent news that there's a race condition allowing exploit of this vulnerability despite applying Steven's patch. We really, really need a patch that checks ownership of the opened file via fstat(2) before providing the contents of the file; we need it now; and we need it included in cPanel by default. Nobody has developed a patch like this yet, but it's the correct solution.

Pointing to CloudLinux or other 3rd party fixes, IMO, just isn't good enough - this is a serious gaping hole in core software provided by cPanel, and this is an opportunity for cPanel to step up pace to demonstrate it's willing to take it's mantle of market leadership seriously when called on.

Sorry to be so blunt (it's beer o'clock here in Australia); obviously I'm a big fan of cPanel but this hole really makes me nervous.

Thanks for the forthcoming response! :)
 
Last edited:
  • Like
Reactions: MaraBlue

JeffP.

Well-Known Member
Sep 28, 2010
164
15
68
I don't disagree. If there were a 12 page thread in the Feature Requests for cPanel & WHM for this, then there may be a better chance of seeing a patch implemented from cPanel. I urge one of you to create a thread there, and email/tweet/facebook/text/whatever the link to everyone you know, asking them to reply to it with their support.

You guys should also be voicing your opinion toward those responsible for this issue, which is the Apache group. The fact that they create an unsafe feature while providing another feature as a workaround which their own documentation says isn't even effective is puzzling. If everyone in the hosting industry who is concerned about this issue demanded from Apache that they address this problem, this thread may not have ever been necessary.

Keep the updates coming. I stand with you guys and will voice my support as well. This shouldn't have ever been an issue, and absolutely shouldn't still be an issue.
 
Last edited by a moderator:
  • Like
Reactions: MaraBlue

JeffP.

Well-Known Member
Sep 28, 2010
164
15
68
We really, really need a patch that checks ownership of the opened file via fstat(2) before providing the contents of the file;
As Igor from CloudLinux mentioned here and here, unfortunately that's not entirely effective, and thus wouldn't be a true solution.
 

AmirolAhmad

Member
Aug 6, 2012
6
0
1
cPanel Access Level
Root Administrator
I can disable madspot shell from symlink to any user in my server. Just prevent php.ini overwritten/uploaded by user and don't allow .htaccess FollowSymlink BUT all my client has an error.. Fuhh there are too many support ticket that we are facing now.

I can't use CloudLinux since I'm on OpenVZ..
 

rs-freddo

Well-Known Member
May 13, 2003
828
1
168
Australia
cPanel Access Level
Root Administrator
I don't disagree. If there were a 12 page thread in the Feature Requests for cPanel & WHM for this, then there may be a better chance of seeing a patch implemented from cPanel. I urge one of you to create a thread there, and email/tweet/facebook/text/whatever the link to everyone you know, asking them to reply to it with their support.
Why don't you just move this thread to feature requests....
Cpanel seem to use the excuse that users didn't jump through hoops 1-20 and that's why nothing is being done. Sorry doesn't make sense - if you value your software surely a cpanel staff member would bring issues to the attention of cpanel devs....?
 

Infopro

Well-Known Member
May 20, 2003
17,076
521
613
Pennsylvania
cPanel Access Level
Root Administrator
Twitter
Why don't you just move this thread to feature requests....
Cpanel seem to use the excuse that users didn't jump through hoops 1-20 and that's why nothing is being done. Sorry doesn't make sense - if you value your software surely a cpanel staff member would bring issues to the attention of cpanel devs....?
Hi Michael, I've asked the cPanel Product Manager @cPanelKenneth about this. His comments mirror cPanelJeff's, above. "This is an Operating System vendor issue. Patching Apache is only a partial solution and the patches available are still subject to race conditions. cPanel is not an Operating System vendor, does not touch the kernel, nor most tools on the system. Taking this to the Vendor is the way to go and/or using something like GRSecurity to solve the problem."

That reads to me like this is out of cPanel's hands, not an excuse full of hoops to jump thru.

I hope that post makes sense to you.
 

qwerty

Well-Known Member
Jan 21, 2003
215
2
168
So is there still no 100% foolproof solution to this ? Even Steven's patch is not immune to race condition?
 

nospa

Well-Known Member
Apr 23, 2012
110
0
66
cPanel Access Level
Reseller Owner
Stevens patch + good disable_functions in php.ini + disable cgi server wide + disable zip unpacking by users + permanent cron control = 99% safety....
 

lbeachmike

Well-Known Member
Dec 27, 2001
307
4
318
Long Beach, NY
cPanel Access Level
Root Administrator
Stevens patch + good disable_functions in php.ini + disable cgi server wide + disable zip unpacking by users + permanent cron control = 99% safety....
I don't follow the 99% safety. 99% safety is not safety if the hackers are aware to exploit the 1% unsafe scenarios, right? Then again, I suppose there really is no such thing as 100% safety :)
 

qwerty

Well-Known Member
Jan 21, 2003
215
2
168
Do you mind explaining what you mean by "disable cgi server wide" and also "zip unpacking". And what functions do you normally disable in php.ini ?
 

nospa

Well-Known Member
Apr 23, 2012
110
0
66
cPanel Access Level
Reseller Owner
You need to disable "ExecCGI" and "Options All" in .htaccess files for Apache configuration. You can do this by disallowing Opions override in httpd.conf , and disabling ExecCGI prior to this.

You can disable zip unpacking (or any archive unpacking) by editing cPanel file manager options and also by removing ZIP from php.

- - - Updated - - -

Then again, I suppose there really is no such thing as 100% safety :)
That is why I post: 99% not 100.... there is no 100% security.
 

feldon27

Well-Known Member
Mar 12, 2003
130
31
178
Houston, TX
Shocked that an advisory e-mail hasn't been sent out to cPanel users with discussion of this issue and potential solutions.

In my case, I implemented this change:
Code:
<Directory "/home">
Options +All -ExecCGI -FollowSymLinks +Includes +IncludesNOEXEC -Indexes -MultiViews +SymLinksIfOwnerMatch
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
</Directory>
to my /usr/local/apache/conf/includes/pre_virtualhost_global.conf

and then did this to find all the .htaccess files on my server that contain +FollowSymLinks:

Code:
find /home -iname ".htaccess" -exec grep -l "FollowSymLinks" {} \;
and systematically went through all of them and changed +FollowSymLinks to +SymLinksIfOwnerMatch.

All in all about 5 minutes work.
 
Last edited:

DomineauX

Well-Known Member
PartnerNOC
Apr 12, 2003
429
11
168
Houston, TX
cPanel Access Level
Root Administrator
Shocked that an advisory e-mail hasn't been sent out to cPanel users with discussion of this issue and potential solutions.

In my case, I implemented this change:
Code:
<Directory "/home">
Options +All -ExecCGI -FollowSymLinks +Includes +IncludesNOEXEC -Indexes -MultiViews +SymLinksIfOwnerMatch
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
</Directory>
to my /usr/local/apache/conf/includes/pre_virtualhost_global.conf

and then did this to find all the .htaccess files on my server that contain +FollowSymLinks:

Code:
find /home -iname ".htaccess" -exec grep -l "FollowSymLinks" {} \;
and systematically went through all of them and changed +FollowSymLinks to +SymLinksIfOwnerMatch.

All in all about 5 minutes work.

Glad to hear that the solution I provided was useful to you.
This change really does work well and isn't tough to implement at all, it just requires a bit of support going forward to keep your users informed of what they need to change in their .htaccess files if they try to use +FollowSymLinks (such as some common scripts like Joomla provide by default).
 

hostnex

Well-Known Member
May 2, 2008
77
1
58
Islamabad, Pakistan, Pakistan
cPanel Access Level
Root Administrator
what about to follow the steps given below. will these steps help in anyway ? :)

+Steven patch

+Restrict safe_mode globally with the help of suphp .

+Disable dangerous php functions through php.ini .

+Disable options ExecCGI +FollowSymLinks+Includes+Indexes under Main >> Service Configuration >> Apache Configuration >> Global Configuration

+Disable the option Automatically create a cgi-bin script alias under Main >> Server Configuration >> Basic cPanel & WHM Setup
 
Status
Not open for further replies.